From owner-namedroppers@ops.ietf.org Sat Oct 01 02:42:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELb4g-0000mI-9v for dnsext-archive@megatron.ietf.org; Sat, 01 Oct 2005 02:42:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27494 for ; Sat, 1 Oct 2005 02:42:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELaxf-000FjT-BW for namedroppers-data@psg.com; Sat, 01 Oct 2005 06:35:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ELaxe-000Fj1-5l for namedroppers@ops.ietf.org; Sat, 01 Oct 2005 06:35:06 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j916Z0eh041814 for ; Sat, 1 Oct 2005 08:35:00 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.3/8.13.3/Submit) id j916Z09O041812 for namedroppers@ops.ietf.org; Sat, 1 Oct 2005 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Sat, 1 Oct 2005 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200510010635.j916Z09O041812@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 01 09:01:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELh01-0003dL-V0 for dnsext-archive@megatron.ietf.org; Sat, 01 Oct 2005 09:01:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00743 for ; Sat, 1 Oct 2005 09:01:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELgtZ-000JzH-5a for namedroppers-data@psg.com; Sat, 01 Oct 2005 12:55:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELgtX-000Jyw-Q4 for namedroppers@ops.ietf.org; Sat, 01 Oct 2005 12:55:16 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9185C4544; Sat, 1 Oct 2005 14:55:14 +0200 (CEST) Date: Sat, 1 Oct 2005 14:55:14 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: DNSSEC explanation, comments? Message-ID: <20051001125513.GA6409@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Mon Oct 03 15:55:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWPl-0003IO-SC for dnsext-archive@megatron.ietf.org; Mon, 03 Oct 2005 15:55:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28428 for ; Mon, 3 Oct 2005 15:55:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMWKD-000LjD-4D for namedroppers-data@psg.com; Mon, 03 Oct 2005 19:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EMWKC-000Liu-2R for namedroppers@ops.ietf.org; Mon, 03 Oct 2005 19:50:12 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006L8-By; Mon, 03 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-44.txt Message-Id: Date: Mon, 03 Oct 2005 15:50:02 -0400 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 Tue Oct 04 09:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMn0L-00012p-0i for dnsext-archive@megatron.ietf.org; Tue, 04 Oct 2005 09:38:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19360 for ; Tue, 4 Oct 2005 09:38:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMmuq-0003HP-VN for namedroppers-data@psg.com; Tue, 04 Oct 2005 13:33:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EMmuo-0003Gh-75 for namedroppers@ops.ietf.org; Tue, 04 Oct 2005 13:33:06 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j94DWhOR053842; Tue, 4 Oct 2005 15:32:43 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <200509220808.j8M88Q2K018623@staff.nominet.org.uk> 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 Message-Id: <5C8236A5-3C83-4836-859C-8905666206E2@NLnetLabs.nl> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: comments on p-s Date: Tue, 4 Oct 2005 15:32:43 +0200 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 Content-Transfer-Encoding: 7bit -----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 SallyEnglish@pricelesspitbulls.net Wed Oct 05 00:17:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN0j4-0004p9-PO for dnsext-archive@megatron.ietf.org; Wed, 05 Oct 2005 00:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26892 for ; Wed, 5 Oct 2005 00:17:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN0rq-0005a4-Ah for dnsext-archive@ietf.org; Wed, 05 Oct 2005 00:27:01 -0400 Received: from [218.17.92.221] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EN0im-0003Ka-QH for dnsext-archive@ietf.org; Wed, 05 Oct 2005 00:17:38 -0400 Received: from a0e4@localhost by xCt.int (8.11.6/8.11.6); Tue, 04 Oct 2005 23:30:58 -0600 Message-ID: From: "Linda Gary" Reply-To: "Linda Gary" To: dnsext-archive@ietf.org Subject: Photoshop CS2 9.0 $69.95 Win XP Date: Wed, 05 Oct 2005 08:27:58 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SallyEnglish@pricelesspitbulls.net Content-Type: multipart/mixed; boundary="--FQRaxJq6tEjg1v3aAZv" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 vRHA ----FQRaxJq6tEjg1v3aAZv Content-Type: text/html; Content-Transfer-Encoding: quoted-printable A
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

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

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: BYTgwLf3
 

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Expires:<= /b> August 31st, 2005
Average Customer Re= view:3D"5 Based on 1974 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: HHKkWXJI
 =

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

<= p>Microsoft Windows XP Professional or Longhorn Edition
Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: tni= jx4F
 

Sales Rank: #3
System requir= ements  |  Other Versions<= /a>
Date Coupon Expires: August 31st,= 2005
Average Customer Review:3D"5 Based on 1286 reviews. Write a review<= /a>.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

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



Availability: A= vailable for INSTANT download!
Coupon Code: ny8gsN
 

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

=

<= /form> ----FQRaxJq6tEjg1v3aAZv-- From owner-namedroppers@ops.ietf.org Wed Oct 05 04:14:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4QB-0004at-5D for dnsext-archive@megatron.ietf.org; Wed, 05 Oct 2005 04:14:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05220 for ; Wed, 5 Oct 2005 04:14:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EN4Kp-000GdJ-LD for namedroppers-data@psg.com; Wed, 05 Oct 2005 08:09:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EN4Ko-000Gcn-1D for namedroppers@ops.ietf.org; Wed, 05 Oct 2005 08:09:06 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j95891gc001051 for ; Wed, 5 Oct 2005 10:09:01 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Namedroppers From: "Olaf M. Kolkman" Subject: Rollover pointed questions. Date: Wed, 5 Oct 2005 10:09:02 +0200 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----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 Wed Oct 05 13:51:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDQY-0003ex-Es for dnsext-archive@megatron.ietf.org; Wed, 05 Oct 2005 13:51:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06911 for ; Wed, 5 Oct 2005 13:51:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENDMA-000BB7-Kw for namedroppers-data@psg.com; Wed, 05 Oct 2005 17:47:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENDM9-000BAq-Ix for namedroppers@ops.ietf.org; Wed, 05 Oct 2005 17:47:05 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2557D568AA; Wed, 5 Oct 2005 10:47:03 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20051005132115.08449740@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 05 Oct 2005 13:47:32 -0400 To: "Olaf M. Kolkman" , Namedroppers From: Mike StJohns Subject: Re: Rollover pointed questions. In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Wed Oct 05 14:07:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDgE-0001Yt-J7 for dnsext-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:07:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07672 for ; Wed, 5 Oct 2005 14:07:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENDd1-000Cog-0A for namedroppers-data@psg.com; Wed, 05 Oct 2005 18:04:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENDcz-000CoD-A7 for namedroppers@ops.ietf.org; Wed, 05 Oct 2005 18:04:29 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j95I4NlX019733 for ; Wed, 5 Oct 2005 20:04:23 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Namedroppers From: "Olaf M. Kolkman" Subject: WGLC: Name Server Identifier Option Date: Wed, 5 Oct 2005 20:04:14 +0200 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----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 Wed Oct 05 14:16:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDo9-0004b5-UR for dnsext-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:16:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07997 for ; Wed, 5 Oct 2005 14:16:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENDmP-000Dgb-4R for namedroppers-data@psg.com; Wed, 05 Oct 2005 18:14:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENDmO-000DgL-Bk for namedroppers@ops.ietf.org; Wed, 05 Oct 2005 18:14:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j95IE97b021569; Wed, 5 Oct 2005 18:14:09 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j95IE9n4021566; Wed, 5 Oct 2005 18:14:09 GMT Date: Wed, 5 Oct 2005 18:14:09 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Fwd: Summary of the LLMNR Last Call Message-ID: <20051005181409.GD20529@vacation.karoshi.com.> References: <20050921171259.9F0EF11449@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Thu Oct 06 02:25:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPCG-0002EW-1u for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 02:25:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10480 for ; Thu, 6 Oct 2005 02:25:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENP6B-00037I-TQ for namedroppers-data@psg.com; Thu, 06 Oct 2005 06:19:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENP6A-00036V-GA for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 06:19:22 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8D16E33C1A; Thu, 6 Oct 2005 07:19:10 +0100 (BST) Message-ID: <4344C164.3060804@algroup.co.uk> Date: Thu, 06 Oct 2005 07:17:08 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike StJohns CC: "Olaf M. Kolkman" , Namedroppers Subject: Re: Rollover pointed questions. References: <6.2.1.2.2.20051005132115.08449740@localhost> 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 owner-namedroppers@ops.ietf.org Thu Oct 06 07:04:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTY6-0002Zu-Ly for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 07:04:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24723 for ; Thu, 6 Oct 2005 07:04:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENTSm-000OgU-3t for namedroppers-data@psg.com; Thu, 06 Oct 2005 10:59:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENTSl-000Og8-DY for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 10:58:59 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Oct 2005 03:58:58 -0700 X-IronPort-AV: i="3.97,181,1125903600"; d="scan'208"; a="663874630:sNHT3980912188" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j96Awp4w014405; Thu, 6 Oct 2005 03:58:55 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 06:58:54 -0400 Received: from 10.86.240.191 ([10.86.240.191]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Oct 2005 10:58:53 +0000 Received: from localhost.localdomain by email.cisco.com; 06 Oct 2005 10:59:06 +0000 Subject: DDNS-DHCP documents through WG last call From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 06 Oct 2005 06:59:05 -0400 Message-Id: <1128596345.7223.88.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 06 Oct 2005 10:58:54.0160 (UTC) FILETIME=[F12B1500:01C5CA64] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 06 07:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENUHM-0006d7-Jz for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 07:51:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26806 for ; Thu, 6 Oct 2005 07:51:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENUEJ-0002or-Fb for namedroppers-data@psg.com; Thu, 06 Oct 2005 11:48:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENUEI-0002of-OV for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 11:48:06 +0000 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 541359; Thu, 06 Oct 2005 07:49:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 6 Oct 2005 07:48:09 -0400 To: Bernard Aboba From: Margaret Wasserman Subject: Re: Response to LLMNR Last Call Comments Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Thu Oct 06 09:19:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVeT-00063c-TA for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 09:19:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01968 for ; Thu, 6 Oct 2005 09:19:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENVZg-000A5M-QZ for namedroppers-data@psg.com; Thu, 06 Oct 2005 13:14:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENVZg-000A58-4T for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 13:14:16 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1ENVZf-000GpO-0c; Thu, 06 Oct 2005 09:14:15 -0400 Received: by internaut.com (Postfix, from userid 1000) id 5F89F56879; Thu, 6 Oct 2005 06:14:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 5110D250BB; Thu, 6 Oct 2005 06:14:16 -0700 (PDT) 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 Date: Thu, 6 Oct 2005 06:14:16 -0700 (PDT) From: Bernard Aboba To: Margaret Wasserman cc: namedroppers@ops.ietf.org Subject: Re: Response to LLMNR Last Call Comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 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 owner-namedroppers@ops.ietf.org Thu Oct 06 10:05:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWNc-0004ns-Cx for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 10:05:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05050 for ; Thu, 6 Oct 2005 10:05:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENWJC-000Dfz-Mg for namedroppers-data@psg.com; Thu, 06 Oct 2005 14:01:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENWJB-000Dfh-UU for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 14:01:18 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j96E13gX081858; Thu, 6 Oct 2005 10:01:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20051006095840.03e2c598@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 06 Oct 2005 10:00:53 -0400 To: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DDNS-DHCP documents through WG last call In-Reply-To: <1128596345.7223.88.camel@localhost.localdomain> References: <1128596345.7223.88.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 06 15:54:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbpI-0007jP-8v for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:54:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27375 for ; Thu, 6 Oct 2005 15:54:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENbl2-000GO3-AV for namedroppers-data@psg.com; Thu, 06 Oct 2005 19:50:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENbl1-000GNg-NF for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 19:50:23 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkg-0002py-2s; Thu, 06 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-45.txt Message-Id: Date: Thu, 06 Oct 2005 15:50:02 -0400 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 Thu Oct 06 15:55:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbpX-0007li-B6 for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:55:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27416 for ; Thu, 6 Oct 2005 15:55:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENbkh-000GKJ-Lq for namedroppers-data@psg.com; Thu, 06 Oct 2005 19:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENbkg-000GJi-PM for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkf-0002pM-Re; Thu, 06 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-name-p-s-01.txt Message-Id: Date: Thu, 06 Oct 2005 15:50:01 -0400 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 Thu Oct 06 17:26:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdGV-0001lq-9G for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 17:26:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17681 for ; Thu, 6 Oct 2005 17:26:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENdCW-000Ojt-QI for namedroppers-data@psg.com; Thu, 06 Oct 2005 21:22:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENdCW-000Oje-3C for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 21:22:52 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7EAA95692F; Thu, 6 Oct 2005 14:22:51 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Thu, 6 Oct 2005 14:22:49 -0700 To: "Olaf M.Kolkman" X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 06 21:28:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENh25-0004kS-Ir for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 21:28:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01459 for ; Thu, 6 Oct 2005 21:28:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENgxE-000H93-Hx for namedroppers-data@psg.com; Fri, 07 Oct 2005 01:23:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENgxB-000H8n-WF for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 01:23:18 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j971IusQ010435 for ; Thu, 6 Oct 2005 21:18:56 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKTaWxu; Thu, 6 Oct 05 21:18:52 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j971KqUD024654 for ; Thu, 6 Oct 2005 21:20:52 -0400 (EDT) Date: Thu, 6 Oct 2005 21:20:52 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 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 Thu Oct 06 22:17:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENhnU-000172-EO for dnsext-archive@megatron.ietf.org; Thu, 06 Oct 2005 22:17:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03112 for ; Thu, 6 Oct 2005 22:17:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENhjV-000LcL-Uz for namedroppers-data@psg.com; Fri, 07 Oct 2005 02:13:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENhjV-000Lbg-6X for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 02:13:13 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 90BEE56830; Thu, 6 Oct 2005 19:13:10 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20051006215313.07134950@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 06 Oct 2005 22:13:38 -0400 To: Samuel Weiler , Namedroppers From: Mike StJohns Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_112862467==.ALT" 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 Oct 07 02:30:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlkQ-0004d7-35 for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 02:30:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27932 for ; Fri, 7 Oct 2005 02:30:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENlfX-000F4T-8v for namedroppers-data@psg.com; Fri, 07 Oct 2005 06:25:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENlfW-000F4C-68 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 06:25:22 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 7BAE967800 for ; Fri, 7 Oct 2005 06:25:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j976P8jL064256; Fri, 7 Oct 2005 16:25:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200510070625.j976P8jL064256@drugs.dv.isc.org> To: Mike StJohns Cc: Samuel Weiler , Namedroppers From: Mark Andrews Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of "Thu, 06 Oct 2005 22:13:38 -0400." <6.2.1.2.2.20051006215313.07134950@localhost> Date: Fri, 07 Oct 2005 16:25:08 +1000 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 Oct 07 02:51:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENm4f-00033H-Jp for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 02:51:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29154 for ; Fri, 7 Oct 2005 02:51:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENlzq-000Gks-Tz for namedroppers-data@psg.com; Fri, 07 Oct 2005 06:46:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENlzq-000Gke-4b for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 06:46:22 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 0AF66226 for ; Fri, 7 Oct 2005 02:46:21 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 558C941A7 for ; Fri, 7 Oct 2005 02:46:20 -0400 (EDT) Date: Fri, 07 Oct 2005 02:46:20 -0400 From: Rob Austein To: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: <6.2.1.2.2.20051006215313.07134950@localhost> References: <6.2.1.2.2.20051006215313.07134950@localhost> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051007064620.558C941A7@thrintun.hactrn.net> 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 Oct 07 02:52:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENm5R-0003Em-Du for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 02:52:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29173 for ; Fri, 7 Oct 2005 02:52:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENm3L-000GzF-2G for namedroppers-data@psg.com; Fri, 07 Oct 2005 06:49:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENm3K-000Gyo-B1 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 06:49:58 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 4087D116 for ; Fri, 7 Oct 2005 02:49:57 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8563941A7 for ; Fri, 7 Oct 2005 02:49:56 -0400 (EDT) Date: Fri, 07 Oct 2005 02:49:56 -0400 From: Rob Austein To: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: <200510070625.j976P8jL064256@drugs.dv.isc.org> References: <6.2.1.2.2.20051006215313.07134950@localhost> <200510070625.j976P8jL064256@drugs.dv.isc.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051007064956.8563941A7@thrintun.hactrn.net> 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 Oct 07 03:03:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmGo-0006B6-G6 for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 03:03:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29623 for ; Fri, 7 Oct 2005 03:03:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENmEG-000IM7-UP for namedroppers-data@psg.com; Fri, 07 Oct 2005 07:01:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENmEG-000ILs-92 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 07:01:16 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id B397B5690E; Fri, 7 Oct 2005 00:01:15 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <20051007064956.8563941A7@thrintun.hactrn.net> 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 Message-Id: <2EB41A60-617A-4A5A-B9B5-EBECB3875E18@nominum.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 00:01:12 -0700 To: Rob Austein X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 07 03:09:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmMT-0007bK-TJ for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 03:09:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29938 for ; Fri, 7 Oct 2005 03:09:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENmKk-000JK1-G9 for namedroppers-data@psg.com; Fri, 07 Oct 2005 07:07:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENmKj-000JJY-Mw for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 07:07:57 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 2C26656821; Fri, 7 Oct 2005 00:07:57 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <200510070625.j976P8jL064256@drugs.dv.isc.org> 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 Message-Id: <41EF7BFC-8E43-42D3-833E-D9F805DE6BF0@nominum.com> Cc: Mike StJohns , Samuel Weiler , Namedroppers Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 00:07:55 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 07 05:01:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENo6t-0000wD-4I for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 05:01:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05453 for ; Fri, 7 Oct 2005 05:01:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENo42-0002t4-H3 for namedroppers-data@psg.com; Fri, 07 Oct 2005 08:58:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENo40-0002sj-V5 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 08:58:49 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j978wf509509; Fri, 7 Oct 2005 10:58:41 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j978wfmo071154; Fri, 7 Oct 2005 10:58:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510070858.j978wfmo071154@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of Wed, 05 Oct 2005 20:04:14 +0200. Date: Fri, 07 Oct 2005 10:58:41 +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 Oct 07 05:25:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENoUF-0007gD-DR for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 05:25:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06257 for ; Fri, 7 Oct 2005 05:25:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENoRM-0005OU-CE for namedroppers-data@psg.com; Fri, 07 Oct 2005 09:22:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENoRK-0005OE-KV for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 09:22:55 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j979MnLe088127; Fri, 7 Oct 2005 11:22:49 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <43342DDE.60602@connotech.com> 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" Message-Id: <988CC235-8093-44C9-BF1F-084ADB619B3D@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Survey of Rollover Mechanisms Date: Fri, 7 Oct 2005 11:22:37 +0200 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 Oct 07 08:50:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrg0-0003WA-JP for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 08:50:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15705 for ; Fri, 7 Oct 2005 08:50:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENrax-000NU1-KP for namedroppers-data@psg.com; Fri, 07 Oct 2005 12:45:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1ENraw-000NT0-Il for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 12:45:02 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j97Cixar019783 for ; Fri, 7 Oct 2005 14:45:00 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j97Cix300034 for ; Fri, 7 Oct 2005 14:44:59 +0200 (MEST) Message-Id: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of "Thu, 06 Oct 2005 14:22:49 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29.1128689094.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Fri, 07 Oct 2005 14:44:59 +0200 From: Peter Koch 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 Oct 07 09:41:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENsTX-0006ty-Ja for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 09:41:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18364 for ; Fri, 7 Oct 2005 09:41:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENsQ3-0001xP-ID for namedroppers-data@psg.com; Fri, 07 Oct 2005 13:37:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENsQ3-0001xB-0t for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 13:37:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8615A11424; Fri, 7 Oct 2005 13:37:50 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: Your message of "Wed, 05 Oct 2005 20:04:14 +0200." References: Date: Fri, 07 Oct 2005 13:37:50 +0000 Message-Id: <20051007133750.8615A11424@sa.vix.com> 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 Oct 07 09:52:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENseU-0000oj-3Z for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 09:52:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18931 for ; Fri, 7 Oct 2005 09:52:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENsbj-0002yB-6P for namedroppers-data@psg.com; Fri, 07 Oct 2005 13:49:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENsbi-0002xz-Kf for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 13:49:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2F8A311425; Fri, 7 Oct 2005 13:49:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Peter Koch cc: IETF DNSEXT WG Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: Your message of "Fri, 07 Oct 2005 14:44:59 +0200." <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> References: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Fri, 07 Oct 2005 13:49:54 +0000 Message-Id: <20051007134954.2F8A311425@sa.vix.com> 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 Oct 07 11:36:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENuHG-00081N-4o for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 11:36:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25952 for ; Fri, 7 Oct 2005 11:36:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENuF2-000CSe-8G for namedroppers-data@psg.com; Fri, 07 Oct 2005 15:34:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENuF1-000CSO-8s for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 15:34:35 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j97FYSOS088423 for ; Fri, 7 Oct 2005 11:34:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20051007110957.03f3ee68@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 07 Oct 2005 11:33:49 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC summary: Wildcard Clarify Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Oct 07 12:30:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENv7F-0006SL-RE for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 12:30:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28745 for ; Fri, 7 Oct 2005 12:30:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENv30-000Hk1-CD for namedroppers-data@psg.com; Fri, 07 Oct 2005 16:26:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENv2y-000Hja-V3 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 16:26:13 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id CDD5E116 for ; Fri, 7 Oct 2005 12:26:11 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 20D6241A7 for ; Fri, 7 Oct 2005 12:26:11 -0400 (EDT) Date: Fri, 07 Oct 2005 12:26:11 -0400 From: Rob Austein To: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: <20051007133750.8615A11424@sa.vix.com> References: <20051007133750.8615A11424@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051007162611.20D6241A7@thrintun.hactrn.net> 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 Oct 07 13:24:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvxQ-0003cF-A2 for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 13:24:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01317 for ; Fri, 7 Oct 2005 13:24:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENvti-000MyC-Pp for namedroppers-data@psg.com; Fri, 07 Oct 2005 17:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENvti-000Mxy-72 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 17:20:42 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 78067568C2; Fri, 7 Oct 2005 10:20:41 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> 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 Message-Id: <268E7A19-31C4-44F3-87B9-2E327BC1F583@nominum.com> Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 10:20:38 -0700 To: Peter Koch X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 07 13:44:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwGn-0001bX-8s for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 13:44:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02269 for ; Fri, 7 Oct 2005 13:44:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENwES-000Oja-J7 for namedroppers-data@psg.com; Fri, 07 Oct 2005 17:42:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENwER-000OjN-W6 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 17:42:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 88CD211424 for ; Fri, 7 Oct 2005 17:42:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: Your message of "Fri, 07 Oct 2005 12:26:11 -0400." <20051007162611.20D6241A7@thrintun.hactrn.net> References: <20051007133750.8615A11424@sa.vix.com> <20051007162611.20D6241A7@thrintun.hactrn.net> Date: Fri, 07 Oct 2005 17:42:07 +0000 Message-Id: <20051007174207.88CD211424@sa.vix.com> 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 Oct 07 13:52:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwOi-0003qb-VK for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 13:52:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02655 for ; Fri, 7 Oct 2005 13:52:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENwMX-000PSF-SK for namedroppers-data@psg.com; Fri, 07 Oct 2005 17:50:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ENwMV-000PRq-33 for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 17:50:27 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j97HoG1H089198 for ; Fri, 7 Oct 2005 13:50:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20051007134735.03e9aec0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 07 Oct 2005 13:50:12 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: IETF-64 Vancouver DNSEXT agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Oct 07 18:54:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO16L-0001YI-D8 for dnsext-archive@megatron.ietf.org; Fri, 07 Oct 2005 18:54:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01276 for ; Fri, 7 Oct 2005 18:54:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EO12f-0009w5-Jw for namedroppers-data@psg.com; Fri, 07 Oct 2005 22:50:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EO12e-0009vk-Tf for namedroppers@ops.ietf.org; Fri, 07 Oct 2005 22:50:17 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7B0075692F; Fri, 7 Oct 2005 15:50:15 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <20051007162611.20D6241A7@thrintun.hactrn.net> 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 Message-Id: <985F594E-A944-4F27-B525-D4847D1C2A93@nominum.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 11:36:11 -0700 To: Rob Austein X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 10 10:16:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyS5-0000Y3-Or for dnsext-archive@megatron.ietf.org; Mon, 10 Oct 2005 10:16:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11828 for ; Mon, 10 Oct 2005 10:16:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EOyN0-0008cJ-H5 for namedroppers-data@psg.com; Mon, 10 Oct 2005 14:11:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EOyMz-0008bu-J5 for namedroppers@ops.ietf.org; Mon, 10 Oct 2005 14:11:13 +0000 Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9AEBAT5029254 for ; Mon, 10 Oct 2005 16:11:10 +0200 (MEST) Received: from localhost (pk@localhost) by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9AEB9i02542 for ; Mon, 10 Oct 2005 16:11:09 +0200 (MEST) Message-Id: <200510101411.j9AEB9i02542@zeder.TechFak.Uni-Bielefeld.DE> 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 Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of "Fri, 07 Oct 2005 10:20:38 PDT." <268E7A19-31C4-44F3-87B9-2E327BC1F583@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2519.1128953461.1@zeder.TechFak.Uni-Bielefeld.DE> Date: Mon, 10 Oct 2005 16:11:09 +0200 From: Peter Koch 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 Mon Oct 10 16:15:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP43g-0000MR-6n for dnsext-archive@megatron.ietf.org; Mon, 10 Oct 2005 16:15:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22500 for ; Mon, 10 Oct 2005 16:15:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EP409-000CZh-76 for namedroppers-data@psg.com; Mon, 10 Oct 2005 20:12:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EP407-000CZK-UP for namedroppers@ops.ietf.org; Mon, 10 Oct 2005 20:12:00 +0000 Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9AKBvVc000748 for ; Mon, 10 Oct 2005 22:11:57 +0200 (MEST) Received: from localhost (pk@localhost) by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9AKBvx04123 for ; Mon, 10 Oct 2005 22:11:57 +0200 (MEST) Message-Id: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> 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 Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of "Wed, 05 Oct 2005 20:04:14 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4116.1128975112.1@zeder.TechFak.Uni-Bielefeld.DE> Date: Mon, 10 Oct 2005 22:11:57 +0200 From: Peter Koch 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 Mon Oct 10 17:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP5VG-0008PN-TQ for dnsext-archive@megatron.ietf.org; Mon, 10 Oct 2005 17:48:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26762 for ; Mon, 10 Oct 2005 17:48:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EP5Rb-000JF2-3w for namedroppers-data@psg.com; Mon, 10 Oct 2005 21:44:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EP5Ra-000JEq-K5 for namedroppers@ops.ietf.org; Mon, 10 Oct 2005 21:44:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BEDE11424 for ; Mon, 10 Oct 2005 21:44:26 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: Your message of "Mon, 10 Oct 2005 22:11:57 +0200." <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> References: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> Date: Mon, 10 Oct 2005 21:44:26 +0000 Message-Id: <20051010214426.2BEDE11424@sa.vix.com> 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 Mon Oct 10 19:38:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP7Dy-0007rW-3Q for dnsext-archive@megatron.ietf.org; Mon, 10 Oct 2005 19:38:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02324 for ; Mon, 10 Oct 2005 19:38:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EP7BE-0001Ek-Qi for namedroppers-data@psg.com; Mon, 10 Oct 2005 23:35:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EP7BE-0001EJ-90 for namedroppers@ops.ietf.org; Mon, 10 Oct 2005 23:35:40 +0000 Received: by sa.vix.com (Postfix, from userid 716) id CD07D11425; Mon, 10 Oct 2005 23:35:39 +0000 (UTC) To: namedroppers@ops.ietf.org Subject: Re: WGLC: Name Server Identifier Option References: From: Paul Vixie Date: 10 Oct 2005 23:35:39 +0000 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Tue Oct 11 09:56:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKcC-0003iN-4l for dnsext-archive@megatron.ietf.org; Tue, 11 Oct 2005 09:56:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24711 for ; Tue, 11 Oct 2005 09:56:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPKVq-000GyU-1w for namedroppers-data@psg.com; Tue, 11 Oct 2005 13:49:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EPKVm-000Gxq-60 for namedroppers@ops.ietf.org; Tue, 11 Oct 2005 13:49:47 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9BDnbuK034712 for ; Tue, 11 Oct 2005 09:49:37 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j9BDnbw8034711 for namedroppers@ops.ietf.org; Tue, 11 Oct 2005 09:49:37 -0400 (EDT) (envelope-from namedroppers) Received: from [193.0.4.49] (helo=bert-4.secret-wg.org) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENWi0-000GNH-Cg for namedroppers@ops.ietf.org; Thu, 06 Oct 2005 14:26:56 +0000 Received: by bert-4.secret-wg.org (Postfix, from userid 1005) id 07B35B8F4; Thu, 6 Oct 2005 16:26:55 +0200 (CEST) Received: from [213.154.224.54] (grover.secret-wg.org [213.154.224.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by bert-4.secret-wg.org (Postfix) with ESMTP id 41973B82C; Thu, 6 Oct 2005 16:26:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--22244683" Message-Id: <048AF982-100E-4B7B-B0E0-2BAC38FA250C@dacht.net> Cc: Mark Townsley , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Request to advance "white lies documents" Date: Thu, 6 Oct 2005 16:26:50 +0200 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 Tue Oct 11 15:09:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPVV-0006G6-1f for dnsext-archive@megatron.ietf.org; Tue, 11 Oct 2005 15:09:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22929 for ; Tue, 11 Oct 2005 15:09:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPPPB-000Fps-Fw for namedroppers-data@psg.com; Tue, 11 Oct 2005 19:03:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EPPPA-000Fpb-J7 for namedroppers@ops.ietf.org; Tue, 11 Oct 2005 19:03:16 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 1B027154 for ; Tue, 11 Oct 2005 15:03:15 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 629FE41A7 for ; Tue, 11 Oct 2005 15:03:14 -0400 (EDT) Date: Tue, 11 Oct 2005 15:03:14 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: WGLC: Name Server Identifier Option In-Reply-To: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> References: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051011190314.629FE41A7@thrintun.hactrn.net> 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 Thu Oct 13 16:10:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9PO-0001BZ-My for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:10:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12427 for ; Thu, 13 Oct 2005 16:10:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQ9K8-0008Wu-Vl for namedroppers-data@psg.com; Thu, 13 Oct 2005 20:05:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQ9K5-0008WA-Jz for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 20:05:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9DK0gOS011366 for ; Thu, 13 Oct 2005 16:00:42 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdJaqmw; Thu, 13 Oct 05 16:00:39 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9DK2UE0015852; Thu, 13 Oct 2005 16:02:33 -0400 (EDT) Date: Thu, 13 Oct 2005 16:02:30 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC explanation, comments? In-Reply-To: <20051001125513.GA6409@outpost.ds9a.nl> Message-ID: References: <20051001125513.GA6409@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu Oct 13 16:28:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9gq-0004nE-OQ for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:28:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15551 for ; Thu, 13 Oct 2005 16:28:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQ9ex-000ApK-Nm for namedroppers-data@psg.com; Thu, 13 Oct 2005 20:26:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQ9ex-000Ap7-0N for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 20:26:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9DKMFs2013100 for ; Thu, 13 Oct 2005 16:22:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAx_aiKz; Thu, 13 Oct 05 16:22:11 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9DKO6Mi016438; Thu, 13 Oct 2005 16:24:07 -0400 (EDT) Date: Thu, 13 Oct 2005 16:24:06 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism In-Reply-To: <430082DB.7090901@algroup.co.uk> Message-ID: References: <430082DB.7090901@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu Oct 13 17:01:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAD5-00071i-O8 for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 17:01:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17054 for ; Thu, 13 Oct 2005 17:01:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQAAr-000Eot-90 for namedroppers-data@psg.com; Thu, 13 Oct 2005 20:59:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQAAp-000EoU-W3 for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 20:59:36 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DF39B33C1D; Thu, 13 Oct 2005 21:59:33 +0100 (BST) Message-ID: <434ECAB8.8030600@algroup.co.uk> Date: Thu, 13 Oct 2005 21:59:36 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism References: <430082DB.7090901@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 13 17:35:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAjc-0000WJ-47 for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 17:35:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19251 for ; Thu, 13 Oct 2005 17:35:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQAgm-000INJ-N9 for namedroppers-data@psg.com; Thu, 13 Oct 2005 21:32:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQAgl-000IN3-G7 for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 21:32:35 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 263FB405E; Thu, 13 Oct 2005 23:32:34 +0200 (CEST) Date: Thu, 13 Oct 2005 23:32:33 +0200 From: bert hubert To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC explanation, comments? Message-ID: <20051013213233.GC27170@outpost.ds9a.nl> References: <20051001125513.GA6409@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Thu Oct 13 18:07:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBEF-0001By-6Y for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 18:07:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20825 for ; Thu, 13 Oct 2005 18:07:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQBBr-000MNl-6a for namedroppers-data@psg.com; Thu, 13 Oct 2005 22:04:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQBBo-000MN6-31 for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 22:04:40 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9DM4Yv4011520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2005 00:04:35 +0200 From: Simon Josefsson To: bert hubert Cc: namedroppers@ops.ietf.org, Samuel Weiler Subject: Re: DNSSEC explanation, comments? References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> 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 Date: Fri, 14 Oct 2005 00:04:34 +0200 In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> (bert hubert's message of "Thu, 13 Oct 2005 23:32:33 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Thu Oct 13 18:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBIs-0004Jg-VV for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 18:11:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21328 for ; Thu, 13 Oct 2005 18:11:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQBGr-000N9U-Nf for namedroppers-data@psg.com; Thu, 13 Oct 2005 22:09:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQBGq-000N9A-Ut for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 22:09:53 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 13 Oct 2005 18:09:51 -0400 id 005CC9BA.434EDB2F.0000276A Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_cliffie-10090-1129241391-0001-2" In-Reply-To: <434ECAB8.8030600@algroup.co.uk> References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Message-Id: <3085D1B3-B640-41D6-9E91-5DFA16B7144B@verisignlabs.com> From: David Blacka Subject: Re: NSEC3 signalling mechanism Date: Thu, 13 Oct 2005 18:09:50 -0400 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 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 Thu Oct 13 18:16:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBNa-0004kz-Ja for dnsext-archive@megatron.ietf.org; Thu, 13 Oct 2005 18:16:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21528 for ; Thu, 13 Oct 2005 18:16:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQBLX-000Nk1-Qu for namedroppers-data@psg.com; Thu, 13 Oct 2005 22:14:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQBLX-000Njo-6v for namedroppers@ops.ietf.org; Thu, 13 Oct 2005 22:14:43 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 13 Oct 2005 18:14:42 -0400 id 005CC9BA.434EDC52.00002961 In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> 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" Message-Id: <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> Cc: DNSEXT WG From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Thu, 13 Oct 2005 18:14:41 -0400 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 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 Oct 14 02:00:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQIc8-0003MI-Md for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 02:00:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19504 for ; Fri, 14 Oct 2005 02:00:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQIYO-000IfN-Ko for namedroppers-data@psg.com; Fri, 14 Oct 2005 05:56:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQIYN-000If2-EN for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 05:56:27 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5BB114074; Fri, 14 Oct 2005 07:56:24 +0200 (CEST) Date: Fri, 14 Oct 2005 07:56:24 +0200 From: bert hubert To: David Blacka Cc: DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014055623.GA10908@outpost.ds9a.nl> 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 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 Oct 14 04:52:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQLIb-0006iQ-FW for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 04:52:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26678 for ; Fri, 14 Oct 2005 04:52:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQLEE-000EIM-52 for namedroppers-data@psg.com; Fri, 14 Oct 2005 08:47:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQLEC-000EI4-VR for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 08:47:49 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 21AA333C1B; Fri, 14 Oct 2005 09:47:44 +0100 (BST) Message-ID: <434F70B2.40505@algroup.co.uk> Date: Fri, 14 Oct 2005 09:47:46 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> In-Reply-To: <20051014055623.GA10908@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 06:30:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMp7-0002OW-Kk for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:30:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00506 for ; Fri, 14 Oct 2005 06:29:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQMln-000O9D-E5 for namedroppers-data@psg.com; Fri, 14 Oct 2005 10:26:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQMlm-000O8z-Nu for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 10:26:34 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 794ADC2DA8; Fri, 14 Oct 2005 11:26:33 +0100 (BST) Date: Fri, 14 Oct 2005 11:26:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , David Blacka Cc: DNSEXT WG , Alex Bligh Subject: Re: DNSSEC explanation, comments? Message-ID: <8EE515D76E624D3802FA88AB@[192.168.100.25]> In-Reply-To: <20051014055623.GA10908@outpost.ds9a.nl> References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 06:31:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMqx-0002yd-Km for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:31:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00595 for ; Fri, 14 Oct 2005 06:31:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQMpV-000ORw-12 for namedroppers-data@psg.com; Fri, 14 Oct 2005 10:30:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQMpU-000ORW-4E for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 10:30:24 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 65818407E; Fri, 14 Oct 2005 12:30:22 +0200 (CEST) Date: Fri, 14 Oct 2005 12:30:22 +0200 From: bert hubert To: Ben Laurie Cc: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014103021.GA16285@outpost.ds9a.nl> 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 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 Oct 14 06:39:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMxy-0004ZG-0y for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:39:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01198 for ; Fri, 14 Oct 2005 06:39:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQMwP-000P4b-6c for namedroppers-data@psg.com; Fri, 14 Oct 2005 10:37:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQMwO-000P4I-Il for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 10:37:32 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A6345407E; Fri, 14 Oct 2005 12:37:31 +0200 (CEST) Date: Fri, 14 Oct 2005 12:37:31 +0200 From: bert hubert To: Alex Bligh Cc: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014103731.GB16285@outpost.ds9a.nl> 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 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 Oct 14 06:45:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQN40-00077a-1j for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:45:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01564 for ; Fri, 14 Oct 2005 06:45:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQN2T-000Pm7-NY for namedroppers-data@psg.com; Fri, 14 Oct 2005 10:43:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQN2S-000Plq-QS for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 10:43:49 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3538B33C1A; Fri, 14 Oct 2005 11:43:47 +0100 (BST) Message-ID: <434F8BE4.9060200@algroup.co.uk> Date: Fri, 14 Oct 2005 11:43:48 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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> In-Reply-To: <20051014103021.GA16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 06:47:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQN5z-0007lY-6B for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:47:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01645 for ; Fri, 14 Oct 2005 06:47:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQN4Z-000058-WF for namedroppers-data@psg.com; Fri, 14 Oct 2005 10:46:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQN4Z-00004t-Db for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 10:45:59 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 81D7FC2DAA; Fri, 14 Oct 2005 11:45:58 +0100 (BST) Date: Fri, 14 Oct 2005 11:45:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert Cc: David Blacka , DNSEXT WG , Alex Bligh Subject: Re: DNSSEC explanation, comments? Message-ID: <23B62ABDF3A0DC25AD424269@[192.168.100.25]> In-Reply-To: <20051014103731.GB16285@outpost.ds9a.nl> 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 07:03:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNLv-00049T-0U for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:03:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02234 for ; Fri, 14 Oct 2005 07:03:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQNKB-00021e-Kw for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:02:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQNKA-00021N-RU for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:02:07 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7D71644BD; Fri, 14 Oct 2005 13:02:04 +0200 (CEST) Date: Fri, 14 Oct 2005 13:02:04 +0200 From: bert hubert To: Alex Bligh Cc: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014110203.GC16285@outpost.ds9a.nl> 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 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 Oct 14 07:11:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNTC-0006k9-AX for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:11:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02664 for ; Fri, 14 Oct 2005 07:11:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQNRl-0002xY-Av for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:09:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQNRk-0002wa-Lh for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:09:56 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B630BC2DA8; Fri, 14 Oct 2005 12:09:46 +0100 (BST) Date: Fri, 14 Oct 2005 12:09:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert Cc: David Blacka , DNSEXT WG , Alex Bligh Subject: Re: DNSSEC explanation, comments? Message-ID: <7FB724248C95E8664D6EEB07@[192.168.100.25]> In-Reply-To: <20051014110203.GC16285@outpost.ds9a.nl> 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 07:33:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNok-0005WV-1K for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:33:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03851 for ; Fri, 14 Oct 2005 07:33:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQNmV-0005Es-W8 for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:31:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQNmV-0005EU-8U for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:31:23 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2DA6733C1D; Fri, 14 Oct 2005 12:31:21 +0100 (BST) Message-ID: <434F970A.5060305@algroup.co.uk> Date: Fri, 14 Oct 2005 12:31:22 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: Alex Bligh , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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> In-Reply-To: <20051014110203.GC16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 07:37:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNsm-0006iH-Mu for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:37:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03983 for ; Fri, 14 Oct 2005 07:37:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQNrM-0005fM-C0 for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:36:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQNrL-0005f6-IX for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:36:23 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 59DA74636; Fri, 14 Oct 2005 13:36:21 +0200 (CEST) Date: Fri, 14 Oct 2005 13:36:21 +0200 From: bert hubert To: Ben Laurie Cc: Alex Bligh , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014113621.GD16285@outpost.ds9a.nl> 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 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 Oct 14 07:57:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOBj-0003ko-4l for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:57:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04769 for ; Fri, 14 Oct 2005 07:57:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQO9q-0007e0-81 for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:55:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQO9n-0007dL-8x for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:55:27 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9EBt9S1026737; Fri, 14 Oct 2005 07:55:10 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j9EBsrG3025147; Fri, 14 Oct 2005 07:54:53 -0400 (EDT) From: "Scott Rose" To: "bert hubert" Cc: Subject: RE: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 07:54:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <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 Content-Transfer-Encoding: 7bit > -----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 Oct 14 07:58:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOCJ-0003tB-AY for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:58:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04786 for ; Fri, 14 Oct 2005 07:57:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOBB-0007uB-VY for namedroppers-data@psg.com; Fri, 14 Oct 2005 11:56:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQOBA-0007tB-Pc for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 11:56:53 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id ECA6933C1B; Fri, 14 Oct 2005 12:56:48 +0100 (BST) Message-ID: <434F9D02.3050106@algroup.co.uk> Date: Fri, 14 Oct 2005 12:56:50 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: Alex Bligh , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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> In-Reply-To: <20051014113621.GD16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 08:07:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOL8-0007cf-Vq for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:07:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05734 for ; Fri, 14 Oct 2005 08:07:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOJh-0009J6-MX for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:05:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOJh-0009Is-29 for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:05:41 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 19FF2C2DA8; Fri, 14 Oct 2005 13:05:40 +0100 (BST) Date: Fri, 14 Oct 2005 13:05:33 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , bert hubert Cc: David Blacka , DNSEXT WG , Alex Bligh Subject: Re: DNSSEC explanation, comments? Message-ID: <86F457810B84849160970E1C@[192.168.100.25]> In-Reply-To: <434F9D02.3050106@algroup.co.uk> 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 08:13:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQORI-0000oZ-Ue for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:13:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06072 for ; Fri, 14 Oct 2005 08:13:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOPq-000A7i-8v for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQOPp-000A7L-BM for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:12:01 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5166033C1D; Fri, 14 Oct 2005 13:11:59 +0100 (BST) Message-ID: <434FA091.2060704@algroup.co.uk> Date: Fri, 14 Oct 2005 13:12:01 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: bert hubert , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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]> In-Reply-To: <86F457810B84849160970E1C@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 08:10:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQONu-0008VJ-Ns for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:10:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05941 for ; Fri, 14 Oct 2005 08:09:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOMC-0009g1-3R for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:08:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOM6-0009fK-AR for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:08:10 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 14:08:08 +0200 Date: Fri, 14 Oct 2005 14:08:08 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: DNSEXT WG Subject: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) In-Reply-To: <20051014113621.GD16285@outpost.ds9a.nl> Message-ID: 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-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 Oct 14 08:17:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOVT-0001w5-Lf for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:17:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06312 for ; Fri, 14 Oct 2005 08:17:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOUD-000Aif-IP for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:16:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOUC-000AiS-Tf for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:16:33 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id CB7B1C2DA8; Fri, 14 Oct 2005 13:16:31 +0100 (BST) Date: Fri, 14 Oct 2005 13:16:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: bert hubert , David Blacka , DNSEXT WG , Alex Bligh Subject: Re: DNSSEC explanation, comments? Message-ID: <554469BA87B1B496F4AEFC72@[192.168.100.25]> In-Reply-To: <434FA091.2060704@algroup.co.uk> 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 08:21:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOZL-0003UL-9Z for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:21:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06549 for ; Fri, 14 Oct 2005 08:21:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOXx-000BDf-UV for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:20:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOXx-000BDC-Bs for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:20:25 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 97ABCC2DA8; Fri, 14 Oct 2005 13:20:24 +0100 (BST) Date: Fri, 14 Oct 2005 13:20:15 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends , DNSEXT WG Cc: Alex Bligh Subject: Re: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) Message-ID: In-Reply-To: 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Oct 14 08:23:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOau-0003sP-9J for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:23:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06697 for ; Fri, 14 Oct 2005 08:23:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOZc-000BTv-It for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:22:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQOZb-000BTH-Ku for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:22:08 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 884DB33C1A; Fri, 14 Oct 2005 13:22:04 +0100 (BST) Message-ID: <434FA2EE.4060407@algroup.co.uk> Date: Fri, 14 Oct 2005 13:22:06 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: bert hubert , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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]> In-Reply-To: <554469BA87B1B496F4AEFC72@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 14 08:25:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOdB-00053L-MA for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:25:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06816 for ; Fri, 14 Oct 2005 08:25:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQObl-000BoL-Qh for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:24:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQObj-000Bny-81 for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:24:19 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 14:24:17 +0200 Date: Fri, 14 Oct 2005 14:24:17 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Alex Bligh cc: DNSEXT WG Subject: Re: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) In-Reply-To: Message-ID: 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-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 Oct 14 08:30:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOhM-0006fo-Lk for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:30:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07001 for ; Fri, 14 Oct 2005 08:30:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOfu-000CP5-2A for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:28:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOfq-000COU-SW for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:28:35 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B5B2344BF; Fri, 14 Oct 2005 14:28:33 +0200 (CEST) Date: Fri, 14 Oct 2005 14:28:33 +0200 From: bert hubert To: Alex Bligh Cc: Ben Laurie , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014122833.GA19423@outpost.ds9a.nl> 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 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 Oct 14 08:46:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOxU-0002co-SU for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:46:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07564 for ; Fri, 14 Oct 2005 08:46:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOv7-000E2J-6u for namedroppers-data@psg.com; Fri, 14 Oct 2005 12:44:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOv6-000E1p-I3 for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 12:44:20 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 14:44:16 +0200 Date: Fri, 14 Oct 2005 14:44:16 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: bert hubert cc: Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? In-Reply-To: <20051014122833.GA19423@outpost.ds9a.nl> Message-ID: 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 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 IngridFrye@gwtkj.com Fri Oct 14 09:18:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPRh-0004Am-Er for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 09:18:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09007 for ; Fri, 14 Oct 2005 09:17:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPcI-0002xe-TZ for dnsext-archive@ietf.org; Fri, 14 Oct 2005 09:29:01 -0400 Received: from [221.127.153.8] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EQPRR-0003Qr-7T for dnsext-archive@ietf.org; Fri, 14 Oct 2005 09:17:46 -0400 Received: from tXz@localhost by P4r.int (8.11.6/8.11.6); Fri, 14 Oct 2005 19:10:27 +0400 Message-ID: <8EZN2VlZ4jIkampZxtY8sp@healthinsuranceforselfemployedindividual.com> From: "Winnie Walter" Reply-To: "Winnie Walter" To: dn@ietf.org Subject: MS Office XP Pro $49.95 Symantec Date: Fri, 14 Oct 2005 16:14:27 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: IngridFrye@gwtkj.com Content-Type: multipart/mixed; boundary="--IRNMAhYYb44w32j" X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 qkU ----IRNMAhYYb44w32j Content-Type: text/html; Content-Transfer-Encoding: quoted-printable D
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

= =

 = ON SALE NOW!

 1 Office Pro Edition 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
 4 Systemworks Pro 2004 Edition
 5 Flash MX 2004
 = 6 Corel Painter 8
 7 Adobe Acrobat 6.0
 8 Windows 2003 Server
 9 Alias Maya 6.0 Wavefro= nt
 10 Adobe Prem= iere
  See more by = this manufacturer
   Microsoft<= /td>
   Apple Software
  Customers also bought=
   these other items...



=

Micr= osoft Office Professional Edition *2003*
Microsoft
Choose:
<= /td> 
List Price:<= /td>$899.00
Price:$69.99
You Save:$830.01 (92%)


<= br> Availability: Available for INSTANT download!
Coupon Cod= e: ISe229
Media: CD-ROM / Download

System requirements&= nbsp; |  Accessories  = |  Other Versions

= Features:

  • Analyze and manage business information using= Access databases
  • Exchange d= ata with other systems using enhanced XML technology
  • Control information sharing rules with enhanced I= RM technology
  • Easy-to-use wi= zards to create e-mail newsletters and printed marketing materials =
  • More than 20 preformatted business = reports
Sales Rank: #1<= br> Shipping: International/US or via instant download=
Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
<= /table>

----IRNMAhYYb44w32j-- From owner-namedroppers@ops.ietf.org Fri Oct 14 10:15:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQKu-0006eU-0Z for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 10:15:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12808 for ; Fri, 14 Oct 2005 10:14:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQQHy-000P6R-7o for namedroppers-data@psg.com; Fri, 14 Oct 2005 14:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, RCVD_NUMERIC_HELO,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQQHx-000P6E-Ps for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 14:12:01 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2005 07:12:01 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="220177767:sNHT29250126" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9EEBxUw005349; Fri, 14 Oct 2005 07:12:00 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:11:56 -0400 Received: from 161.44.65.150 ([161.44.65.150]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Oct 2005 14:11:56 +0000 Received: from dhcp-guest-bxb22-64-102-164-37.cisco.com by email.cisco.com; 14 Oct 2005 10:12:16 -0400 Subject: Package of DDNS-DHCP drafts ready for review From: Ralph Droms To: Margaret Wasserman , "W.MarkTownsley" Cc: Olafur Gudmundsson , Olaf Kolkman , Stig Venaas , namedroppers@ops.ietf.org, dhcwg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 14 Oct 2005 10:12:16 -0400 Message-Id: <1129299136.5744.26.camel@dhcp-guest-bxb22-64-102-164-37.cisco.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 14 Oct 2005 14:11:56.0629 (UTC) FILETIME=[3C299850:01C5D0C9] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 14 11:05:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQR7o-0000WK-LC for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 11:05:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18928 for ; Fri, 14 Oct 2005 11:05:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQR51-0005EK-Lm for namedroppers-data@psg.com; Fri, 14 Oct 2005 15:02:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQR4y-0005Du-Op for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 15:02:40 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 846FC4661; Fri, 14 Oct 2005 17:02:38 +0200 (CEST) Date: Fri, 14 Oct 2005 17:02:38 +0200 From: bert hubert To: Roy Arends Cc: Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051014150238.GA19821@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Roy Arends , Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG 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 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 Oct 14 13:22:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTGB-0007JS-43 for dnsext-archive@megatron.ietf.org; Fri, 14 Oct 2005 13:22:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01636 for ; Fri, 14 Oct 2005 13:22:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQTDA-000MRm-An for namedroppers-data@psg.com; Fri, 14 Oct 2005 17:19:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQTD9-000MRV-AC for namedroppers@ops.ietf.org; Fri, 14 Oct 2005 17:19:15 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 14 Oct 2005 13:19:13 -0400 id 005CCA42.434FE891.000019E6 In-Reply-To: <20051014150238.GA19821@outpost.ds9a.nl> 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 Message-Id: <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:19:13 -0400 To: bert hubert X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Sun Oct 16 06:07:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER5QP-0001HW-4p for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 06:07:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23437 for ; Sun, 16 Oct 2005 06:07:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER5KZ-0007UF-2l for namedroppers-data@psg.com; Sun, 16 Oct 2005 10:01:27 +0000 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ER5KV-0007U0-GT for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 10:01:23 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E1F10452C; Sun, 16 Oct 2005 12:01:20 +0200 (CEST) Date: Sun, 16 Oct 2005 12:01:20 +0200 From: bert hubert To: David Blacka Cc: DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051016100120.GB5187@outpost.ds9a.nl> 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 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 Sun Oct 16 10:03:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER97E-0005zu-Au for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 10:03:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03301 for ; Sun, 16 Oct 2005 10:03:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER92r-000I0W-1X for namedroppers-data@psg.com; Sun, 16 Oct 2005 13:59:25 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ER92n-000I09-Ng for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 13:59:21 +0000 Received: from [192.168.1.13] ([::ffff:69.255.36.218]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 16 Oct 2005 09:59:20 -0400 id 005D00DA.43525CB8.00001348 In-Reply-To: <20051016100120.GB5187@outpost.ds9a.nl> 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 Message-Id: <138B7A37-9AB2-4EE7-B8BC-E798685FE400@verisignlabs.com> Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 09:59:31 -0400 To: bert hubert X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Sun Oct 16 12:11:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERB6t-0007le-9H for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 12:11:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08728 for ; Sun, 16 Oct 2005 12:11:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERB20-000OQz-55 for namedroppers-data@psg.com; Sun, 16 Oct 2005 16:06:40 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERB1w-000OQd-NR for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 16:06:36 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 18A8333C1B; Sun, 16 Oct 2005 17:06:35 +0100 (BST) Message-ID: <43527A8F.5090204@algroup.co.uk> Date: Sun, 16 Oct 2005 17:06:39 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: bert hubert CC: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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> In-Reply-To: <20051016100120.GB5187@outpost.ds9a.nl> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Sun Oct 16 13:01:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBtS-00047o-Tb for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:01:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10706 for ; Sun, 16 Oct 2005 13:01:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERBqe-0001CT-Dq for namedroppers-data@psg.com; Sun, 16 Oct 2005 16:59:00 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERBqb-0001CE-67 for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 16:58:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BE3AE11425 for ; Sun, 16 Oct 2005 16:58:56 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: DNSEXT WG Subject: Re: DNSSEC explanation, comments? In-Reply-To: Your message of "Sun, 16 Oct 2005 12:01:20 +0200." <20051016100120.GB5187@outpost.ds9a.nl> 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> Date: Sun, 16 Oct 2005 16:58:56 +0000 Message-Id: <20051016165856.BE3AE11425@sa.vix.com> 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 Sun Oct 16 13:20:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCB3-0001OB-DI for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:20:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11338 for ; Sun, 16 Oct 2005 13:19:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERC8a-0002OB-LR for namedroppers-data@psg.com; Sun, 16 Oct 2005 17:17:32 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERC8X-0002Nz-EE for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 17:17:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F291611425; Sun, 16 Oct 2005 17:17:28 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ben Laurie cc: bert hubert , David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? In-Reply-To: Your message of "Sun, 16 Oct 2005 17:06:39 +0100." <43527A8F.5090204@algroup.co.uk> 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> Date: Sun, 16 Oct 2005 17:17:28 +0000 Message-Id: <20051016171728.F291611425@sa.vix.com> 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 Sun Oct 16 13:28:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCJ2-0003HA-OK for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:28:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11608 for ; Sun, 16 Oct 2005 13:28:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERCHW-0002zf-Ee for namedroppers-data@psg.com; Sun, 16 Oct 2005 17:26:46 +0000 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERCHT-0002zP-3C for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 17:26:43 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 88D9944E9; Sun, 16 Oct 2005 19:26:40 +0200 (CEST) Date: Sun, 16 Oct 2005 19:26:40 +0200 From: bert hubert To: Ben Laurie Cc: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051016172639.GA12559@outpost.ds9a.nl> 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 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 Sun Oct 16 13:41:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCVM-00070c-26 for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:41:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12204 for ; Sun, 16 Oct 2005 13:40:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERCTG-0003nZ-4p for namedroppers-data@psg.com; Sun, 16 Oct 2005 17:38:54 +0000 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERCTC-0003nH-Q1 for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 17:38:50 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 64AA544E9; Sun, 16 Oct 2005 19:38:49 +0200 (CEST) Date: Sun, 16 Oct 2005 19:38:49 +0200 From: bert hubert To: Paul Vixie Cc: DNSEXT WG Subject: Re: DNSSEC explanation, comments? Message-ID: <20051016173848.GB12559@outpost.ds9a.nl> 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 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 Sun Oct 16 13:46:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCad-0000SR-NK for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:46:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12534 for ; Sun, 16 Oct 2005 13:46:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERCYl-0004Fe-9E for namedroppers-data@psg.com; Sun, 16 Oct 2005 17:44:35 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERCYh-0004F9-RU for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 17:44:32 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4BB6F33C1A; Sun, 16 Oct 2005 18:44:30 +0100 (BST) Message-ID: <43529182.3010004@algroup.co.uk> Date: Sun, 16 Oct 2005 18:44:34 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: bert hubert CC: David Blacka , DNSEXT WG Subject: Re: DNSSEC explanation, comments? 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> In-Reply-To: <20051016172639.GA12559@outpost.ds9a.nl> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Sun Oct 16 13:49:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCdB-0001J1-HF for dnsext-archive@megatron.ietf.org; Sun, 16 Oct 2005 13:49:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12692 for ; Sun, 16 Oct 2005 13:49:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERCc8-0004aI-Ey for namedroppers-data@psg.com; Sun, 16 Oct 2005 17:48:04 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERCc5-0004Zu-7Q for namedroppers@ops.ietf.org; Sun, 16 Oct 2005 17:48:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BB08311425; Sun, 16 Oct 2005 17:48:00 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: DNSEXT WG Subject: Re: DNSSEC explanation, comments? In-Reply-To: Your message of "Sun, 16 Oct 2005 19:38:49 +0200." <20051016173848.GB12559@outpost.ds9a.nl> 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> Date: Sun, 16 Oct 2005 17:48:00 +0000 Message-Id: <20051016174800.BB08311425@sa.vix.com> 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 katedunghill03@msn.com Mon Oct 17 06:22:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERS82-0002MW-43 for dnsext-archive@megatron.ietf.org; Mon, 17 Oct 2005 06:22:02 -0400 Received: from omc2-s42.bay6.hotmail.com (omc2-s42.bay6.hotmail.com [65.54.249.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01755 for ; Mon, 17 Oct 2005 06:21:51 -0400 (EDT) Received: from hotmail.com ([65.54.173.3]) by omc2-s42.bay6.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 03:21:28 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Oct 2005 03:21:27 -0700 Message-ID: Received: from 216.139.164.163 by by5fd.bay5.hotmail.msn.com with HTTP; Mon, 17 Oct 2005 10:21:27 GMT X-Originating-IP: [216.139.164.163] X-Originating-Email: [katedunghill03@msn.com] X-Sender: katedunghill03@msn.com From: "kate dunghill" Subject: CONTACT THE DIRECTOR OF FINANCE Date: Mon, 17 Oct 2005 10:21:27 +0000 Mime-Version: 1.0 Content-Type: text/html; format=flowed X-OriginalArrivalTime: 17 Oct 2005 10:21:27.0511 (UTC) FILETIME=[889AE670:01C5D304]
BRITISH LOTTERY INTERNATIONAL

 CUSTOMER SERVICE

British Flag                                                             

 

 

 

British Lottery International

Headquarters: 60 Merriman Road
Blackheath London SE3 8RZ
England.

Ref. Number: BTL/491OXI/04
Batch Number: 12/25/0304
Ticket Number: 564 75600545-188
Serial Number: 5388/02
 
Dear Sir/Madam,
 
We are pleased to inform you of the result of the Winners in our British International Lottery Program held on the 17th of October, 2005. Your

e-mail address attached to ticket number 564 75600545-188 with serial number 5388/02 drew lucky numbers 7-14-18-31-45, which consequently won in the 2ND category, you have therefore been approved for a lump sum pay of U.S$500,000.00 (FIVE HUNDRED THOUSAND U.S DOLLARS). This is from a total cash prize of TWO MILLION FIVE HUNDRED U.S DOLLARS  Shared among the FIVE international winners in second categories. CONGRATULATIONS!

Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims have been fully processed and your money remitted to you. This is part of our security protocol to avoid multiple claims and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot  system drawn from over 20,000 company and 30,000,000 individual email addresses and names from all over the world. This promotional program takes place every five years.
 
This lottery was promoted and sponsored by a conglomerate of some multinational companies in Europe as part of their social responsibility to  the citizens. This year Lottery Program Jackpot is the largest ever for British Lottery. The estimated $125 million jackpot would be the sixth biggest in U.K. history. The biggest was the $363 million jackpot that went to two winners in a May 2000 drawing of The Big Game, Mega Millions' predecessor.
To file for your claim, please  contact our director of finance.

Name  :  Dr.Jerry Springwell
E-mail:  j_springwell02@uk2.net
Please note in order to avoid unnecessary delays and complications, remember to quote your reference numbers and batch numbers correctly in all correspondence. Furthermore should there be any change of address do inform our agent as soon as possible.
Congratulations once more from our members of staff and thank you for being part of our promotional program.
 
Note: Anybody under the age of 18 is automatically disqualified.

Yours Sincerely,
Mrs.Kate Dunghill.
British Lottery International (co-coordinator)

 

N.B: Any breach of confidentiality on the part of the winners before payment is effected may lead to disqualification. Please do not reply to this email, Contact our director of finance.

From HopeMeade@ihandpaintglass.com Mon Oct 17 13:16:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYbB-0005D6-Jp for dnsext-archive@megatron.ietf.org; Mon, 17 Oct 2005 13:16:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25422 for ; Mon, 17 Oct 2005 13:16:23 -0400 (EDT) Received: from host-81-190-255-59.elk.mm.pl ([81.190.255.59]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERYm4-0004Vv-G0 for dnsext-archive@ietf.org; Mon, 17 Oct 2005 13:28:16 -0400 Received: from 6oK@localhost by aPtA.int (8.11.6/8.11.6); Mon, 17 Oct 2005 22:09:35 +0400 Message-ID: <6wrw2EotkycqOFIO2kGX6@lernerwomen.com> From: "Sara Gross" Reply-To: "Sara Gross" To: dnsext-archive@ietf.org Cc: nona.dwyer@ietf.org Subject: 0nline software, Download Symantec, XP Pro & others Instantly Date: Mon, 17 Oct 2005 17:04:35 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HopeMeade@ihandpaintglass.com Content-Type: multipart/mixed; boundary="--3AwWxHbHJaxo4LA" X-Spam-Score: 2.8 (++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 BGoI ----3AwWxHbHJaxo4LA Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Y
Choose:
&nbs= p;

List Price:= $279.00
Price:$49.99
You Save:$229.01 (85= %)



Availability: Available for INSTANT download!
Coupon Code: ISe229
M= edia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Fe= atures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability = to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management = solutions

Sales Rank: #2
= Shipping: International/US or via instant download Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Cr= eative Suite Premium
Adobe
=
Choose:=
 

<= b>You Save:



Availability: Available for INSTANT do= wnload!
Coupon Code: ISe229
Media: CD-ROM / Download=

System requirements  |  Accessories  |  Oth= er Versions

Features:

  • An integrated de= sign environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and = comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolse= t
  • Single installer--control = what you install and when you install it
  • Cross-media publishing--create content for both print and the= Web

Sales Rank: #3 Shipping: International/US or via instant download<= br> Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

List Price: $1149.00
Price:$99.99
$849.01 (90%)

Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

=

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

<= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: ivwotu
 

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

<= table border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse:= collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber1 height=3D55= >
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V= 9.0
Adobe<= /a>

Choose:=
 

=
List Price:$599.00
Price:= $69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: He= 2Tjs3
 

Sales Rank: #2
= System requ= irements  |  Other Versio= ns
Date Coupon Expires: August 31= st, 2005
Average Customer Review: Based on 1974 reviews. Write a revie= w.

Microsoft Windows XP Professional or Lon= ghorn Edition
Microsoft

Choose:
 

<= a href=3Dhttp://saveoemnow.net/?V>

$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: BWJ3qV9
 

S= ales Rank: #3
System requirements  |  Other Versions
Date Coupon E= xpires: August 31st, 2005
Average Cus= tomer Review:3D"5 Based on 1777 reviews. Write a review.

Adobe Acrobat Pro= fessional V 7.0
Adobe
<= /p>
Choose:<= td noWrap width=3D38> 

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



A= vailability: Available for INSTANT download!
Coupon Code: K= frWZZ
 

Sales Rank: #4
System requ= irements  |  Other Versio= ns
Date Coupon Expires: August 31= st, 2005
Average Customer Review: Based on 16261 reviews. Write a revi= ew.

<= /td>
----3AwWxHbHJaxo4LA-- From owner-namedroppers@ops.ietf.org Mon Oct 17 19:37:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReYH-0005Pn-DV for dnsext-archive@megatron.ietf.org; Mon, 17 Oct 2005 19:37:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16108 for ; Mon, 17 Oct 2005 19:37:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EReTb-0005uc-PI for namedroppers-data@psg.com; Mon, 17 Oct 2005 23:33:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com 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 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EReTa-0005uO-Lk for namedroppers@ops.ietf.org; Mon, 17 Oct 2005 23:33:06 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00157C; 17 Oct 2005 19:37:36 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 17 Oct 2005 19:37:17 -0400 Received: from connotech.com (209.71.204.118) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00157B; 17 Oct 2005 19:37:12 -0400 Message-ID: <43543C65.5060006@connotech.com> Date: Mon, 17 Oct 2005 20:05:57 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Two drafts for Automated Trust Anchor Key Rollover Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: 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 Tue Oct 18 00:53:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERjTj-00027m-44 for dnsext-archive@megatron.ietf.org; Tue, 18 Oct 2005 00:53:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02630 for ; Tue, 18 Oct 2005 00:53:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERjPQ-000LG3-Ti for namedroppers-data@psg.com; Tue, 18 Oct 2005 04:49:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ERjPQ-000LFp-3Z for namedroppers@ops.ietf.org; Tue, 18 Oct 2005 04:49:08 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9I4mupm079495 for ; Tue, 18 Oct 2005 00:48:57 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20051017155946.03fbdd88@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 18 Oct 2005 00:48:54 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC: RFC2536bis and RFC2539bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Tue Oct 18 16:32:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy8W-0005VZ-Ce for dnsext-archive@megatron.ietf.org; Tue, 18 Oct 2005 16:32:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09891 for ; Tue, 18 Oct 2005 16:32:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERy3W-000725-4e for namedroppers-data@psg.com; Tue, 18 Oct 2005 20:27:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERy3T-00071e-45 for namedroppers@ops.ietf.org; Tue, 18 Oct 2005 20:27:27 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 7934D24601; Tue, 18 Oct 2005 22:27:26 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 84C1D24595; Tue, 18 Oct 2005 22:27:25 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j9IKRPgL028411; Tue, 18 Oct 2005 22:27:25 +0200 Received: from localhost (brettcarr@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id j9IKRPsn029860; Tue, 18 Oct 2005 22:27:25 +0200 X-Authentication-Warning: cow.ripe.net: brettcarr owned process doing -bs Date: Tue, 18 Oct 2005 22:27:25 +0200 (CEST) From: Brett Carr To: bert hubert cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: DNSSEC explanation, comments? In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> Message-ID: References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed Oct 19 20:33:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOMv-0008UP-6Y for dnsext-archive@megatron.ietf.org; Wed, 19 Oct 2005 20:33:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28742 for ; Wed, 19 Oct 2005 20:33:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESOIS-000CLJ-NV for namedroppers-data@psg.com; Thu, 20 Oct 2005 00:28:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESOIP-000CL3-98 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 00:28:37 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j9K0agEe028869 for ; Wed, 19 Oct 2005 17:36:43 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9K0edQ8014158 for ; Wed, 19 Oct 2005 19:40:40 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Oct 2005 20:28:33 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810B40CC70@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: Thierry Moreau , namedroppers@ops.ietf.org Cc: rschroe@sandia.gov 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Thu Oct 20 06:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESY93-0002II-Oj for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:59:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02129 for ; Thu, 20 Oct 2005 06:59:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESY4c-000EwG-Ns for namedroppers-data@psg.com; Thu, 20 Oct 2005 10:55:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESY4b-000EvW-JU for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 10:55:01 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4008D2596C6 for ; Thu, 20 Oct 2005 12:54:26 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03029-06 for ; Thu, 20 Oct 2005 12:54:22 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 201002596C3 for ; Thu, 20 Oct 2005 12:54:22 +0200 (CEST) Date: Thu, 20 Oct 2005 12:55:36 +0200 From: Harald Tveit Alvestrand To: namedroppers@ops.ietf.org Subject: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 20 07:19:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYSP-0002QB-Tx for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 07:19:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03024 for ; Thu, 20 Oct 2005 07:19:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESYQX-000G1w-Mp for namedroppers-data@psg.com; Thu, 20 Oct 2005 11:17:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESYQW-000G1j-Sw for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 11:17:41 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id ECCA467801 for ; Thu, 20 Oct 2005 11:17:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id j9KBHYb6033105; Thu, 20 Oct 2005 21:17:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> To: Harald Tveit Alvestrand Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-reply-to: Your message of "Thu, 20 Oct 2005 12:55:36 +0200." Date: Thu, 20 Oct 2005 21:17:34 +1000 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 Thu Oct 20 07:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYkz-0001ep-AY for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 07:38:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04266 for ; Thu, 20 Oct 2005 07:38:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESYjJ-000H2l-UF for namedroppers-data@psg.com; Thu, 20 Oct 2005 11:37:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESYjJ-000H2Z-9R for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 11:37:05 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E23712596C9; Thu, 20 Oct 2005 13:36:29 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04118-09; Thu, 20 Oct 2005 13:36:26 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F89D2596C6; Thu, 20 Oct 2005 13:36:26 +0200 (CEST) Date: Thu, 20 Oct 2005 13:37:41 +0200 From: Harald Tveit Alvestrand To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> In-Reply-To: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Thu Oct 20 08:19:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZOZ-0002k1-5m for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 08:19:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07304 for ; Thu, 20 Oct 2005 08:19:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESZLc-000J5n-Q2 for namedroppers-data@psg.com; Thu, 20 Oct 2005 12:16:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESZLb-000J5V-5E for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 12:16:39 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9KCGLw7094444; Thu, 20 Oct 2005 08:16:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> Date: Thu, 20 Oct 2005 08:16:39 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Cc: Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 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 Thu Oct 20 09:14:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESaFm-0006kz-2N for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:14:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09906 for ; Thu, 20 Oct 2005 09:14:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESaDa-000M8M-Of for namedroppers-data@psg.com; Thu, 20 Oct 2005 13:12:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.111.8.139] (helo=ppsw-9.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESaDa-000M8B-1B for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 13:12:26 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51466) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1ESaBl-00006d-VC (Exim 4.53) (return-path ); Thu, 20 Oct 2005 14:10:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1ESaBl-0008EB-Kr (Exim 4.53) (return-path ); Thu, 20 Oct 2005 14:10:33 +0100 Date: Thu, 20 Oct 2005 14:10:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-Reply-To: Message-ID: References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu Oct 20 09:17:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESaIH-0007ZW-Dn for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:17:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10064 for ; Thu, 20 Oct 2005 09:17:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESaGo-000MLO-BS for namedroppers-data@psg.com; Thu, 20 Oct 2005 13:15:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com 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 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESaGn-000MKc-56 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 13:15:45 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B5212596C1; Thu, 20 Oct 2005 15:15:09 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06328-10; Thu, 20 Oct 2005 15:15:06 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C7832596C0; Thu, 20 Oct 2005 15:15:06 +0200 (CEST) Date: Thu, 20 Oct 2005 15:16:21 +0200 From: Harald Tveit Alvestrand To: Edward Lewis Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> In-Reply-To: References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 20 09:32:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESaXI-00042K-K8 for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:32:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11020 for ; Thu, 20 Oct 2005 09:32:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESaVA-000NGQ-EU for namedroppers-data@psg.com; Thu, 20 Oct 2005 13:30:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESaV9-000NG3-If for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 13:30:35 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9KDUKmJ094781; Thu, 20 Oct 2005 09:30:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Date: Thu, 20 Oct 2005 09:30:38 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 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 Thu Oct 20 09:46:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESakZ-0003wa-MK for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:46:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12457 for ; Thu, 20 Oct 2005 09:46:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESaib-000OCf-1m for namedroppers-data@psg.com; Thu, 20 Oct 2005 13:44:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=no version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESaia-000OCU-Fx for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 13:44:28 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07BC82596C1; Thu, 20 Oct 2005 15:43:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07443-03; Thu, 20 Oct 2005 15:43:49 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id A471B2596C0; Thu, 20 Oct 2005 15:43:49 +0200 (CEST) Date: Thu, 20 Oct 2005 15:45:05 +0200 From: Harald Tveit Alvestrand To: Edward Lewis Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: All-numeric (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Message-ID: <3C193BD5D16ADA0D52ABFE51@svartdal.hjemme.alvestrand.no> In-Reply-To: References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Thu Oct 20 10:02:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESazz-0007Zb-Vd for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 10:02:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13498 for ; Thu, 20 Oct 2005 10:02:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESay9-000PDB-0i for namedroppers-data@psg.com; Thu, 20 Oct 2005 14:00:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESay7-000PCz-Un for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 14:00:32 +0000 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j9KE0Md3006002; Thu, 20 Oct 2005 15:00:22 +0100 (BST) In-Reply-To: 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 Message-Id: Cc: Harald Tveit Alvestrand , Mark Andrews , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 15:00:16 +0100 To: Edward Lewis X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 20 10:03:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESb0e-0007pT-No for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 10:03:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13591 for ; Thu, 20 Oct 2005 10:02:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESazR-000PJy-RK for namedroppers-data@psg.com; Thu, 20 Oct 2005 14:01:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESazR-000PJk-8H for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 14:01:53 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 481B567805 for ; Thu, 20 Oct 2005 14:01:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id j9KE1gRZ033761; Fri, 21 Oct 2005 00:01:42 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200510201401.j9KE1gRZ033761@drugs.dv.isc.org> To: Edward Lewis Cc: Harald Tveit Alvestrand , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-reply-to: Your message of "Thu, 20 Oct 2005 09:30:38 -0400." Date: Fri, 21 Oct 2005 00:01:42 +1000 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 Thu Oct 20 10:03:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESb12-00089L-Gy for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 10:03:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13731 for ; Thu, 20 Oct 2005 10:03:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESaza-000PLo-Og for namedroppers-data@psg.com; Thu, 20 Oct 2005 14:02:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESazZ-000PL4-Qt for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 14:02:02 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9KE1hXM094954; Thu, 20 Oct 2005 10:01:44 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3C193BD5D16ADA0D52ABFE51@svartdal.hjemme.alvestrand.no> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <3C193BD5D16ADA0D52ABFE51@svartdal.hjemme.alvestrand.no> Date: Thu, 20 Oct 2005 10:02:01 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: All-numeric (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 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 Thu Oct 20 10:15:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESbCf-0007eQ-Ue for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 10:15:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15284 for ; Thu, 20 Oct 2005 10:15:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESbAK-0000KR-Lr for namedroppers-data@psg.com; Thu, 20 Oct 2005 14:13:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESbAK-0000KD-1e for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 14:13:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 99E4A11426 for ; Thu, 20 Oct 2005 14:13:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-Reply-To: Your message of "Thu, 20 Oct 2005 15:16:21 +0200." <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Date: Thu, 20 Oct 2005 14:13:07 +0000 Message-Id: <20051020141307.99E4A11426@sa.vix.com> 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 Thu Oct 20 11:07:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESc1C-0003QN-KX for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 11:07:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21491 for ; Thu, 20 Oct 2005 11:07:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESbxT-0003OJ-At for namedroppers-data@psg.com; Thu, 20 Oct 2005 15:03:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESbxS-0003Ny-7P for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 15:03:54 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C92582596C0; Thu, 20 Oct 2005 17:03:18 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09201-08; Thu, 20 Oct 2005 17:03:15 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 102812596BE; Thu, 20 Oct 2005 17:03:15 +0200 (CEST) Date: Thu, 20 Oct 2005 17:04:31 +0200 From: Harald Tveit Alvestrand To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> In-Reply-To: <20051020141307.99E4A11426@sa.vix.com> References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Thu Oct 20 11:16:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESc9t-0003F2-MY for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 11:16:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22679 for ; Thu, 20 Oct 2005 11:16:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESc7z-0004Bk-LQ for namedroppers-data@psg.com; Thu, 20 Oct 2005 15:14:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESc7y-0004BY-S7 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 15:14:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B388C26C08A; Thu, 20 Oct 2005 17:14:45 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 93FEC26C00E; Thu, 20 Oct 2005 17:14:44 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j9KFEiYa931103; Thu, 20 Oct 2005 17:14:44 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 674B216A9A4; Thu, 20 Oct 2005 17:14:44 +0200 (CEST) Date: Thu, 20 Oct 2005 17:14:44 +0200 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Cc: namedroppers@ops.ietf.org Subject: Reservations of labels at all levels considered VERY BAD (Was: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <20051020151444.GA28736@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 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 Thu Oct 20 11:24:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScHa-00054m-Ip for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 11:24:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23215 for ; Thu, 20 Oct 2005 11:24:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EScFE-0004l0-83 for namedroppers-data@psg.com; Thu, 20 Oct 2005 15:22:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EScFD-0004kj-IW for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 15:22:15 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 116222596CD; Thu, 20 Oct 2005 17:21:40 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09767-07; Thu, 20 Oct 2005 17:21:34 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52F842596C6; Thu, 20 Oct 2005 17:21:34 +0200 (CEST) Date: Thu, 20 Oct 2005 17:22:50 +0200 From: Harald Tveit Alvestrand To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: Reservations of labels at all levels considered VERY BAD (Was: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <3D9D6F41822539E1D14B1E45@svartdal.hjemme.alvestrand.no> In-Reply-To: <20051020151444.GA28736@nic.fr> References: <20051020151444.GA28736@nic.fr> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 VivianCompton@westsuburbanhomes.net Thu Oct 20 11:31:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScOB-0001UC-Cs for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 11:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23670 for ; Thu, 20 Oct 2005 11:31:19 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESca6-0005wl-L4 for dnsext-archive@ietf.org; Thu, 20 Oct 2005 11:43:51 -0400 Received: from 218-166-160-129.dynamic.hinet.net ([218.166.160.129]) by mx2.foretec.com with smtp (Exim 4.24) id 1EScO2-0001OA-8c for dnsext-archive@ietf.org; Thu, 20 Oct 2005 11:31:22 -0400 Received: from oRx@localhost by xOu.int (8.11.6/8.11.6); Thu, 20 Oct 2005 23:29:01 +0600 Message-ID: From: "Paula Key" Reply-To: "Paula Key" To: dnsext-archive@ietf.org Cc: dominick.vang@ietf.org Subject: 80 % Discount on All Adobe, Windows Titles Date: Thu, 20 Oct 2005 14:28:01 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VivianCompton@westsuburbanhomes.net Content-Type: multipart/mixed; boundary="--3jedVIS1GSd5aoL6Izgc" X-Spam-Score: 0.3 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 aVn ----3jedVIS1GSd5aoL6Izgc Content-Type: text/html; Content-Transfer-Encoding: quoted-printable I
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
<= /td>

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro Edition 2003
 2 Wi= ndows XP Pro
 3 Adobe Cre= ative Suite Premium
 4 S= ystemworks Pro 2004 Edition
 5 Flash MX 2004
 6 = Corel Painter 8
 7 Adobe = Acrobat 6.0
 8 Windows 2= 003 Server
 = 9 Alias Maya= 6.0 Wavefront
 10 Adobe Pre= miere
  See more by= this manufacturer
   Microsoft
   = Apple Software
&nb= sp; Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
=
Choose:
=  
= =
List Price:$899.00
Price:$69.99
You = Save:$830.01 (92%)

=

Availability: Available for INSTANT download! Coupon Code: ISe229
Media: CD-ROM / Download

System requirem= ents  |  Accessories = ; |  Other Versions

Features:

  • Analyze and manage business information using Acce= ss databases
  • Exchange data w= ith other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM te= chnology
  • Easy-to-use wizards= to create e-mail newsletters and printed marketing materials
    • =
  • More than 20 preformatted business repor= ts
Sales Rank: #1
<= b class=3Dtiny>Shipping: International/US or via instant download
= Date Coupon Expires: May 30th, 2005
<= b>Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft= Windows XP Professional or Longhorn Edition
<= a href=3Dhttp://oemnow.com/?r>Microsoft
Choose:
 =

List Price:= $279.00
Price:$49.99
You Save:$229.01 (85%)



Av= ailability: Available for INSTANT download!
Coupon Code: IS= e229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features= :

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to enc= rypt files and folders
  • Built= -in voice, video, and instant messaging support
  • Integration with Windows servers and management soluti= ons

Sales Rank: #2
Shipping: International/US or via instant download
D= ate Coupon Expires: May 30th, 2005
Av= erage Customer Review: 3D"5 Based on 868 reviews. Write a review.

<= table border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse:= collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber2 height=3D33= 7>
Adobe Creative Suite P= remium
Adobe
Choose:
 =

List Price: $1149.00
Price:$99.99
You Save:$849.= 01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Me= dia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrat= ed design environment featuring the industry's foremost design tools <= /font>
  • In-depth tips, expert tricks,= and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and = toolset
  • Single installer--co= ntrol what you install and when you install it
  • Cross-media publishing--create content for both print a= nd the Web

Sales Rank: #3
Shipping: International/US or via instant dow= nload
Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

=

----3jedVIS1GSd5aoL6Izgc-- From owner-namedroppers@ops.ietf.org Thu Oct 20 12:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd3j-0007u5-Jp for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:14:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26320 for ; Thu, 20 Oct 2005 12:14:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESd1O-0008GH-KG for namedroppers-data@psg.com; Thu, 20 Oct 2005 16:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESd1O-0008G3-0E for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 16:12:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9A6E411425 for ; Thu, 20 Oct 2005 16:12:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-Reply-To: Your message of "Thu, 20 Oct 2005 17:04:31 +0200." <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> 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> Date: Thu, 20 Oct 2005 16:12:01 +0000 Message-Id: <20051020161201.9A6E411425@sa.vix.com> 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 Thu Oct 20 12:40:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdT7-0007W2-Lq for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:40:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28643 for ; Thu, 20 Oct 2005 12:40:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESdRs-000AHO-AD for namedroppers-data@psg.com; Thu, 20 Oct 2005 16:39:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESdRr-000AHC-M2 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 16:39:23 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E3502596CD; Thu, 20 Oct 2005 18:38:48 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12104-04; Thu, 20 Oct 2005 18:38:45 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB9762596C1; Thu, 20 Oct 2005 18:38:44 +0200 (CEST) Date: Thu, 20 Oct 2005 18:40:01 +0200 From: Harald Tveit Alvestrand To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <9E29B66129C7E7D4BD8221A4@svartdal.hjemme.alvestrand.no> In-Reply-To: <20051020161201.9A6E411425@sa.vix.com> 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> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Thu Oct 20 12:40:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdTJ-0007Yl-1e for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:40:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28678 for ; Thu, 20 Oct 2005 12:40:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESdRD-000AED-5a for namedroppers-data@psg.com; Thu, 20 Oct 2005 16:38:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESdRC-000ADt-7Y for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 16:38:42 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83EFA2596CE; Thu, 20 Oct 2005 18:38:06 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11898-08; Thu, 20 Oct 2005 18:38:01 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C16C2596CD; Thu, 20 Oct 2005 18:38:01 +0200 (CEST) Date: Thu, 20 Oct 2005 18:39:17 +0200 From: Harald Tveit Alvestrand To: Paul Vixie , namedroppers@ops.ietf.org Subject: 2821 and friends (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Message-ID: In-Reply-To: <20051020161201.9A6E411425@sa.vix.com> 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> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 20 13:16:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESe25-0004Wx-7B for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 13:16:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01205 for ; Thu, 20 Oct 2005 13:16:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESdyv-000Cbj-Kq for namedroppers-data@psg.com; Thu, 20 Oct 2005 17:13:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESdys-000CbU-Q5 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 17:13:30 +0000 Received: from [207.65.71.19] (pool-70-21-86-248.res.east.verizon.net [70.21.86.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 86A8DD284; Thu, 20 Oct 2005 12:13:29 -0500 (CDT) Message-ID: <4357D032.1030801@ehsco.com> Date: Thu, 20 Oct 2005 13:13:22 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: 2821 and friends (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Oct 20 18:53:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjI0-00076T-08 for dnsext-archive@megatron.ietf.org; Thu, 20 Oct 2005 18:53:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20595 for ; Thu, 20 Oct 2005 18:53:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESjEc-0007tV-HY for namedroppers-data@psg.com; Thu, 20 Oct 2005 22:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESjEb-0007tJ-Sl for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 22:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESjEY-000673-2y; Thu, 20 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt Message-Id: Date: Thu, 20 Oct 2005 18:50:02 -0400 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 Oct 21 03:30:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESrM4-0003VW-Ik for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 03:30:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03467 for ; Fri, 21 Oct 2005 03:30:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESrHL-0006rB-9r for namedroppers-data@psg.com; Fri, 21 Oct 2005 07:25:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESrHI-0006qp-1U for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 07:25:24 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9L7PK3c022883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Oct 2005 09:25:21 +0200 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt References: 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 Date: Fri, 21 Oct 2005 09:25:19 +0200 In-Reply-To: (Internet-Drafts@ietf.org's message of "Thu, 20 Oct 2005 18:50:02 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Oct 21 04:03:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESrrg-0004MG-Up for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 04:03:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04858 for ; Fri, 21 Oct 2005 04:02:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESrol-0008XS-4T for namedroppers-data@psg.com; Fri, 21 Oct 2005 07:59:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESroj-0008XB-QT for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 07:59:58 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9L7xs5t034024; Fri, 21 Oct 2005 09:59:54 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: 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" Message-Id: <3A53F776-2E5C-4214-B866-EDE358EFC081@NLnetLabs.nl> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt Date: Fri, 21 Oct 2005 09:59:52 +0200 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > >> 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 Oct 21 10:01:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxSO-00027s-Iu for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:01:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23188 for ; Fri, 21 Oct 2005 10:01:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESxOX-0001Jm-BI for namedroppers-data@psg.com; Fri, 21 Oct 2005 13:57:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com 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 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESxOW-0001Ja-FY for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 13:57:16 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001E41; 21 Oct 2005 10:01:35 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 21 Oct 2005 10:01:22 -0400 Received: from connotech.com (209.71.204.113) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001E40; 21 Oct 2005 10:01:12 -0400 Message-ID: <4358FB66.2060302@connotech.com> Date: Fri, 21 Oct 2005 10:29:58 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 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 References: <62173B970AE0A044AED8723C3BCF23810B40CC70@ma19exm01.e6.bcs.mot.com> In-Reply-To: <62173B970AE0A044AED8723C3BCF23810B40CC70@ma19exm01.e6.bcs.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Oct 21 10:17:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxhr-00033h-3i for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:17:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24078 for ; Fri, 21 Oct 2005 10:17:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESxfz-0002Vl-OJ for namedroppers-data@psg.com; Fri, 21 Oct 2005 14:15:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESxfy-0002VZ-VB for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 14:15:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 168E926C08A; Fri, 21 Oct 2005 16:15:18 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1BA2526C07B; Fri, 21 Oct 2005 16:15:17 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j9LEFGYa658124; Fri, 21 Oct 2005 16:15:17 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id E394D16A9F2; Fri, 21 Oct 2005 16:15:16 +0200 (CEST) Date: Fri, 21 Oct 2005 16:15:16 +0200 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <20051021141516.GA10102@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 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 Oct 21 10:24:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxpB-0005VO-4e for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:24:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24441 for ; Fri, 21 Oct 2005 10:24:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESxni-00033h-7O for namedroppers-data@psg.com; Fri, 21 Oct 2005 14:23:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESxnh-00033U-J7 for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 14:23:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D820426C08A; Fri, 21 Oct 2005 16:23:16 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id C3E6726C07B; Fri, 21 Oct 2005 16:23:15 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j9LENFYa652073; Fri, 21 Oct 2005 16:23:15 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id A80DE16A9F2; Fri, 21 Oct 2005 16:23:15 +0200 (CEST) Date: Fri, 21 Oct 2005 16:23:15 +0200 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: <20051021142315.GA11002@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 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 Oct 21 10:27:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxrb-0007hE-BS for dnsext-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:27:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24595 for ; Fri, 21 Oct 2005 10:27:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESxq3-0003Gi-Bo for namedroppers-data@psg.com; Fri, 21 Oct 2005 14:25:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [144.189.100.101] (helo=motgate2.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESxpy-0003Fb-4d for namedroppers@ops.ietf.org; Fri, 21 Oct 2005 14:25:42 +0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j9LEecAg009243 for ; Fri, 21 Oct 2005 07:40:38 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9LEWFno001811 for ; Fri, 21 Oct 2005 09:32:16 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Oct 2005 10:25:35 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810B46FC2D@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: Thierry Moreau 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 Date: Fri, 21 Oct 2005 10:25:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Sat Oct 22 02:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCwJ-0006m3-U4 for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 02:33:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21919 for ; Sat, 22 Oct 2005 02:33:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETCqt-0004hr-NE for namedroppers-data@psg.com; Sat, 22 Oct 2005 06:27:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.51.128.198] (helo=smtpq3.home.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETCqs-0004hd-R0 for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 06:27:34 +0000 Received: from [213.51.128.134] (port=47376 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1ESiJK-0006OF-J0 for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 23:50:54 +0200 Received: from cc730311-a.ensch1.ov.home.nl ([82.75.151.113]:63017 helo=cc730311-a) by smtp3.home.nl with esmtp (Exim 4.30) id 1ESiJJ-0005xo-JL for namedroppers@ops.ietf.org; Thu, 20 Oct 2005 23:50:53 +0200 Date: Thu, 20 Oct 2005 23:50:48 +0200 From: Roy Arends X-X-Sender: roy@cc730311-a To: namedroppers@ops.ietf.org Subject: base32 alphabet rant - rhaaaaa rfc3548 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sat Oct 22 08:52:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETIrU-00024b-OR for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 08:52:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10165 for ; Sat, 22 Oct 2005 08:52:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETImX-0001he-Vi for namedroppers-data@psg.com; Sat, 22 Oct 2005 12:47:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETImW-0001hO-GT for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 12:47:28 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MClG1P007019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2005 14:47:16 +0200 From: Simon Josefsson To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::LJrvjAT+WACgK/Qb:MOt X-Hashcash: 1:21:051022:roy@dnss.ec::CQRrO7mV2nEBojUR:EgN8 Date: Sat, 22 Oct 2005 14:47:13 +0200 In-Reply-To: (Roy Arends's message of "Thu, 20 Oct 2005 23:50:48 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > 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 Sat Oct 22 10:45:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKcX-00015l-2O for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 10:45:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14774 for ; Sat, 22 Oct 2005 10:45:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETKZT-0008ej-TD for namedroppers-data@psg.com; Sat, 22 Oct 2005 14:42:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETKZT-0008eY-9z for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 14:42:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D945011426 for ; Sat, 22 Oct 2005 14:42:06 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Sat, 22 Oct 2005 14:47:13 +0200." References: Date: Sat, 22 Oct 2005 14:42:06 +0000 Message-Id: <20051022144206.D945011426@sa.vix.com> 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 Sat Oct 22 11:05:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKvi-0004ou-PD for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 11:05:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15549 for ; Sat, 22 Oct 2005 11:04:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETKtQ-000A1c-Bj for namedroppers-data@psg.com; Sat, 22 Oct 2005 15:02:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETKtP-000A1K-CW for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 15:02:43 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AE27B33C1A; Sat, 22 Oct 2005 16:02:41 +0100 (BST) Message-ID: <435A5497.3010709@algroup.co.uk> Date: Sat, 22 Oct 2005 16:02:47 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> In-Reply-To: <20051022144206.D945011426@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # > 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 Sat Oct 22 11:48:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETLbx-0004RX-HA for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 11:48:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17288 for ; Sat, 22 Oct 2005 11:48:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETLYl-000D8H-G3 for namedroppers-data@psg.com; Sat, 22 Oct 2005 15:45:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETLYi-000D7w-OZ for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 15:45:25 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MFjJfa020932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2005 17:45:19 +0200 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> 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 Date: Sat, 22 Oct 2005 17:45:16 +0200 In-Reply-To: <20051022144206.D945011426@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 14:42:06 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Sat Oct 22 12:49:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMYr-0007S1-2N for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 12:49:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20102 for ; Sat, 22 Oct 2005 12:49:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETMW0-000Gx4-EB for namedroppers-data@psg.com; Sat, 22 Oct 2005 16:46:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETMVy-000Gwg-12 for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 16:46:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9CD9911425 for ; Sat, 22 Oct 2005 16:46:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Sat, 22 Oct 2005 17:45:16 +0200." References: <20051022144206.D945011426@sa.vix.com> Date: Sat, 22 Oct 2005 16:46:37 +0000 Message-Id: <20051022164637.9CD9911425@sa.vix.com> 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 Sat Oct 22 13:12:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMvI-0005Ke-2f for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:12:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21517 for ; Sat, 22 Oct 2005 13:12:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETMsW-000Ief-KD for namedroppers-data@psg.com; Sat, 22 Oct 2005 17:09:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETMsT-000IeO-Oh for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 17:09:54 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MH9nOG029165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2005 19:09:50 +0200 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> 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 Date: Sat, 22 Oct 2005 19:09:47 +0200 In-Reply-To: <20051022164637.9CD9911425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 16:46:37 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Sat Oct 22 13:17:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMzb-0000B7-2h for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:17:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21676 for ; Sat, 22 Oct 2005 13:17:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETMxi-000J4a-0Y for namedroppers-data@psg.com; Sat, 22 Oct 2005 17:15:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETMxh-000J4P-Hr for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 17:15:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 19A9711425 for ; Sat, 22 Oct 2005 17:15:17 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Sat, 22 Oct 2005 19:09:47 +0200." References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> Date: Sat, 22 Oct 2005 17:15:17 +0000 Message-Id: <20051022171517.19A9711425@sa.vix.com> 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 Sat Oct 22 14:07:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNlj-0005Jy-Ty for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:07:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23793 for ; Sat, 22 Oct 2005 14:06:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETNiz-000NC0-Su for namedroppers-data@psg.com; Sat, 22 Oct 2005 18:04:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETNiy-000NBo-Qv for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 18:04:09 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MI3kUL000990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2005 20:03:59 +0200 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> 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 Date: Sat, 22 Oct 2005 20:03:38 +0200 In-Reply-To: <20051022171517.19A9711425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 17:15:17 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Sat Oct 22 14:27:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETO5D-0006by-RX for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:27:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24577 for ; Sat, 22 Oct 2005 14:26:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETO2u-000OZP-QN for namedroppers-data@psg.com; Sat, 22 Oct 2005 18:24:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETO2t-000OZC-Kx for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 18:24:44 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MIOcgn002268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2005 20:24:38 +0200 From: Simon Josefsson To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:roy@dnss.ec::4Y0HB6qsv1KqZfYA:4nNe X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::Y1Ph+btMFQ6zbDEF:7wvS Date: Sat, 22 Oct 2005 20:24:35 +0200 In-Reply-To: (Roy Arends's message of "Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: >>> 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 Sat Oct 22 15:19:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETOta-0003RN-T0 for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 15:19:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25972 for ; Sat, 22 Oct 2005 15:18:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETOqI-0001xY-CZ for namedroppers-data@psg.com; Sat, 22 Oct 2005 19:15:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETOqF-0001xL-V2 for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 19:15:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8424F11425 for ; Sat, 22 Oct 2005 19:15:43 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Sat, 22 Oct 2005 20:03:38 +0200." References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> Date: Sat, 22 Oct 2005 19:15:43 +0000 Message-Id: <20051022191543.8424F11425@sa.vix.com> 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 Sat Oct 22 19:04:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETSPV-0006mm-GS for dnsext-archive@megatron.ietf.org; Sat, 22 Oct 2005 19:04:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03256 for ; Sat, 22 Oct 2005 19:04:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETSKT-000GPZ-Ju for namedroppers-data@psg.com; Sat, 22 Oct 2005 22:59:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETSKQ-000GNU-5L for namedroppers@ops.ietf.org; Sat, 22 Oct 2005 22:59:06 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9MMwtQb021229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Oct 2005 00:58:56 +0200 From: Simon Josefsson To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:roy@dnss.ec::6yk66gXUvlMwKT69:2I4E X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::N8fc5vVdFbBqr5Vv:PM1M Date: Sun, 23 Oct 2005 00:58:52 +0200 In-Reply-To: (Roy Arends's message of "Sat, 22 Oct 2005 21:23:15 +0200 (W. Europe Daylight Time)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > On Sat, 22 Oct 2005, Simon Josefsson wrote: > >> Roy Arends writes: >> >>>>> 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 Sun Oct 23 11:46:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETi3F-0006Xv-Fx for dnsext-archive@megatron.ietf.org; Sun, 23 Oct 2005 11:46:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11646 for ; Sun, 23 Oct 2005 11:46:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EThyl-000Nqi-6K for namedroppers-data@psg.com; Sun, 23 Oct 2005 15:41:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EThyk-000NqX-Fx for namedroppers@ops.ietf.org; Sun, 23 Oct 2005 15:41:46 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 23 Oct 2005 08:41:46 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Oct 2005 08:41:45 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Oct 2005 08:41:45 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Oct 2005 08:41:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: base32 alphabet rant - rhaaaaa rfc3548 Date: Sun, 23 Oct 2005 08:41:45 -0700 Message-ID: Thread-Topic: base32 alphabet rant - rhaaaaa rfc3548 Thread-Index: AcXXXVPEMzpc1N+URxO6i1dW/UP70wAUokMg From: "Christian Huitema" To: "Simon Josefsson" , "Roy Arends" Cc: X-OriginalArrivalTime: 23 Oct 2005 15:41:45.0049 (UTC) FILETIME=[45A0FC90:01C5D7E8] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > 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 Sun Oct 23 12:15:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETiVj-0008VD-NP for dnsext-archive@megatron.ietf.org; Sun, 23 Oct 2005 12:15:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13421 for ; Sun, 23 Oct 2005 12:15:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETiTL-000PqH-Gb for namedroppers-data@psg.com; Sun, 23 Oct 2005 16:13:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETiTI-000Ppy-JB for namedroppers@ops.ietf.org; Sun, 23 Oct 2005 16:13:21 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9NGD3oa021363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Oct 2005 18:13:04 +0200 From: Simon Josefsson To: "Christian Huitema" Cc: , "Roy Arends" Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: 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 Date: Sun, 23 Oct 2005 18:13:00 +0200 In-Reply-To: (Christian Huitema's message of "Sun, 23 Oct 2005 08:41:45 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "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 SamanthaKnapp@cricketwireless.org Sun Oct 23 14:31:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETkcb-0001Ch-Bi for dnsext-archive@megatron.ietf.org; Sun, 23 Oct 2005 14:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19122 for ; Sun, 23 Oct 2005 14:30:52 -0400 (EDT) Received: from [221.126.136.81] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETkpA-0002Pn-AP for dnsext-archive@ietf.org; Sun, 23 Oct 2005 14:44:07 -0400 Received: from Yp7@localhost by cBT.int (8.11.6/8.11.6); Sun, 23 Oct 2005 18:25:39 -0200 Message-ID: From: "Giselle Finkel" Reply-To: "Giselle Finkel" To: dnsext-archive@ietf.org Cc: dominick.vang@ietf.org Subject: AutoCAD Products available for Download Date: Mon, 24 Oct 2005 02:25:39 +0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SamanthaKnapp@cricketwireless.org Content-Type: multipart/mixed; boundary="--cjQHm7IMj5hOdxH4" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 X08p ----cjQHm7IMj5hOdxH4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
<= /table>
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= table cellSpacing=3D0 cellPadding=3D0 width=3D155 border=3D0>
SEARCH
=

TOP 10 NEW TITLES

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

 = ;1 Office Pro Edition 2003
2= Windows XP Pro
 3= Adobe Creative Suite Premiu= m
 4 Syste= mworks Pro 2004 Edition
  <= font face=3Dverdana,arial,helvetica size=3D1> Flash MX 2004
 = ;6 Corel Painter 8
 7 Adobe Acrobat 6.0
8 Windows 2003 Server
 9 Alias Maya 6.0 Wavef= ront
 10 A= dobe Premiere
  See= more by this manufacturer
&n= bsp;  Micro= soft
  = Apple = Software
  Customer= s also bought
   these other items.= .



Microsoft Office Professional Edition = *2003*
Microsoft
Choose:
&nb= sp;
List Price:$899.00
Price:$69.99
You Save:$830.01 (92%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requireme= nts  |  Accesso= ries  |  Other = Versions

Features:

  • Analyze and manage busi= ness information using Access databases
  • Exchange data with other systems using enhanced XML technology=
  • Control information sharing= rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marke= ting materials
  • More than 20 = preformatted business reports
= Sales Rank: #1
Shipping: International/US o= r via instant download
Date Coupon Expires: May 30th, 2005
= Average Customer Review: 3D"5 Based o= n 1,768 reviews. Write a revi= ew.
Microsoft Windows XP Professional or Longh= orn Edition
Microsoft <= /span>
Choose:
 

= =
List Price:$279.00
Price:$49.99
You = Save:$229.01 (85%)

<= a href=3Dhttp://septembersoftoutlets.com/?n>

Availability: Available for INSTANT= download!
Coupon Code: ISe229
Media: CD-ROM / Downl= oad

System requirements  |  Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: May 30th, 2005
= Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
=  

List Price: $1149.00
Price:$99.99
You Save:$849.01 (90%)



Availability: Available for INSTANT download!
Coup= on Code: ISe229
Media: CD-ROM / Download

System requ= irements  |  Ac= cessories  |  O= ther Versions

Features:

  • An integrated = design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, an= d comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and too= lset
  • Single installer--contr= ol what you install and when you install it
  • Cross-media publishing--create content for both print and = the Web

Sales Rank: #= 3
Shipping: International/US or via instant downlo= ad
Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

=

----cjQHm7IMj5hOdxH4-- From owner-namedroppers@ops.ietf.org Sun Oct 23 22:09:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETrlq-00020Z-78 for dnsext-archive@megatron.ietf.org; Sun, 23 Oct 2005 22:09:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06842 for ; Sun, 23 Oct 2005 22:08:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETrhw-000CH0-GF for namedroppers-data@psg.com; Mon, 24 Oct 2005 02:05:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.51.128.198] (helo=smtpq3.home.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETrht-000CFK-L2 for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 02:05:01 +0000 Received: from [213.51.128.135] (port=45194 helo=smtp4.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1ETNe6-0000UN-Su; Sat, 22 Oct 2005 19:59:06 +0200 Received: from cc730311-a.ensch1.ov.home.nl ([82.75.151.113]:63023 helo=cc730311-a) by smtp4.home.nl with esmtp (Exim 4.30) id 1ETNe5-0000H2-L4; Sat, 22 Oct 2005 19:59:05 +0200 Date: Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time) From: Roy Arends To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Message-ID: References: X-X-Sender: roy@trinitario.schlyter.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 24 03:18:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwaz-0001It-MY for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 03:18:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21266 for ; Mon, 24 Oct 2005 03:17:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETwXU-0003Je-RD for namedroppers-data@psg.com; Mon, 24 Oct 2005 07:14:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.51.128.198] (helo=smtpq3.home.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETwXT-0003JQ-VP for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 07:14:36 +0000 Received: from [213.51.128.134] (port=35474 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1ETm4m-00031n-VD; Sun, 23 Oct 2005 22:04:16 +0200 Received: from cc730311-a.ensch1.ov.home.nl ([82.75.151.113]:62426 helo=cc730311-a) by smtp3.home.nl with esmtp (Exim 4.30) id 1ETm4l-00053I-KE; Sun, 23 Oct 2005 22:04:15 +0200 Date: Sun, 23 Oct 2005 22:04:12 +0200 (W. Europe Daylight Time) From: Roy Arends To: Christian Huitema cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: RE: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Message-ID: References: X-X-Sender: roy@trinitario.schlyter.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 24 03:50:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETx66-0002lG-Rm for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 03:50:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22959 for ; Mon, 24 Oct 2005 03:50:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETx46-0004zg-Ec for namedroppers-data@psg.com; Mon, 24 Oct 2005 07:48:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETx45-0004zU-BV for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 07:48:17 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9O7mF1E064953 for ; Mon, 24 Oct 2005 09:48:15 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <20051022164637.9CD9911425@sa.vix.com> References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12--638442272" Message-Id: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 09:48:16 +0200 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 Mon Oct 24 03:57:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxCd-0004ZL-MK for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 03:57:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23270 for ; Mon, 24 Oct 2005 03:56:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETxB5-0005Pr-3W for namedroppers-data@psg.com; Mon, 24 Oct 2005 07:55:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1ETxB3-0005Pa-MG for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 07:55:30 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9O7tPCf000108 for ; Mon, 24 Oct 2005 09:55:27 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9O7tOb23536 for ; Mon, 24 Oct 2005 09:55:24 +0200 (MEST) Message-Id: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-reply-to: Your message of "Sat, 22 Oct 2005 16:46:37 -0000." <20051022164637.9CD9911425@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23531.1130140514.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Mon, 24 Oct 2005 09:55:23 +0200 From: Peter Koch 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 Mon Oct 24 04:09:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxOl-00089C-MQ for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:09:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23932 for ; Mon, 24 Oct 2005 04:09:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETxN0-0006Sr-T6 for namedroppers-data@psg.com; Mon, 24 Oct 2005 08:07:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETxMv-0006SF-7u for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 08:07:45 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 10:07:42 +0200 Date: Mon, 24 Oct 2005 10:07:42 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Message-ID: 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 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 Mon Oct 24 04:22:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxaw-0002gv-JR for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:22:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24430 for ; Mon, 24 Oct 2005 04:21:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETxY5-0007bA-T3 for namedroppers-data@psg.com; Mon, 24 Oct 2005 08:19:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETxY5-0007at-9t for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 08:19:17 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 10:17:54 +0200 Date: Mon, 24 Oct 2005 10:17:54 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Peter Koch cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 24 06:33:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzda-0003NR-6m for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:33:06 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00253 for ; Mon, 24 Oct 2005 06:32:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETzaX-000GBn-OH for namedroppers-data@psg.com; Mon, 24 Oct 2005 10:29:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETzaW-000GBa-Ee for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 10:29:56 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4EEE933C1A; Mon, 24 Oct 2005 11:29:51 +0100 (BST) Message-ID: <435CB7A6.6040500@algroup.co.uk> Date: Mon, 24 Oct 2005 11:29:58 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Peter Koch CC: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 06:33:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzda-0003O8-Kh for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:33:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00256 for ; Mon, 24 Oct 2005 06:32:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETzb0-000GFU-2n for namedroppers-data@psg.com; Mon, 24 Oct 2005 10:30:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ETzaz-000GEL-02 for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 10:30:25 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 44DCA33C1A; Mon, 24 Oct 2005 11:30:20 +0100 (BST) Message-ID: <435CB7C3.2000307@algroup.co.uk> Date: Mon, 24 Oct 2005 11:30:27 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Roy Arends CC: "Olaf M. Kolkman" , Namedroppers Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 07:35:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0cQ-0003VA-9F for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:35:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03391 for ; Mon, 24 Oct 2005 07:35:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU0Yw-000KLO-Ki for namedroppers-data@psg.com; Mon, 24 Oct 2005 11:32:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EU0Yv-000KLD-Kc for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 11:32:22 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9OBWJq3021859 for ; Mon, 24 Oct 2005 13:32:19 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9OBWJI25434 for ; Mon, 24 Oct 2005 13:32:19 +0200 (MEST) Message-Id: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-reply-to: Your message of "Mon, 24 Oct 2005 11:29:58 BST." <435CB7A6.6040500@algroup.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25421.1130153526.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Mon, 24 Oct 2005 13:32:18 +0200 From: Peter Koch 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 Mon Oct 24 07:58:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0xw-0000rc-2Y for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:58:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04505 for ; Mon, 24 Oct 2005 07:57:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU0wE-000Lxm-Bb for namedroppers-data@psg.com; Mon, 24 Oct 2005 11:56:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EU0wB-000LxY-KF for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 11:56:23 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BC93F405F; Mon, 24 Oct 2005 13:56:20 +0200 (CEST) Date: Mon, 24 Oct 2005 13:56:20 +0200 From: bert hubert To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Message-ID: <20051024115620.GB24941@outpost.ds9a.nl> References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Mon Oct 24 08:14:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1Du-0006PY-1L for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:14:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05976 for ; Mon, 24 Oct 2005 08:14:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU1C7-000MwX-Cr for namedroppers-data@psg.com; Mon, 24 Oct 2005 12:12:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EU1C6-000MwL-PC for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 12:12:50 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from libra.cus.cam.ac.uk ([131.111.8.19]:58251) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EU1Br-0004b2-6Q (Exim 4.53) for namedroppers@ops.ietf.org (return-path ); Mon, 24 Oct 2005 13:12:35 +0100 Received: from cet1 by libra.cus.cam.ac.uk with local (Exim 4.54) id 1EU1Br-0001kC-Ju for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 13:12:35 +0100 Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 To: namedroppers@ops.ietf.org Date: Mon, 24 Oct 2005 13:12:35 +0100 (BST) 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] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 09:48:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2gS-0008A8-Nc for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:48:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10605 for ; Mon, 24 Oct 2005 09:48:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU2d6-0001yS-IW for namedroppers-data@psg.com; Mon, 24 Oct 2005 13:44:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU2d5-0001yA-9R for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 13:44:47 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9ODiYpB010261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2005 15:44:38 +0200 From: Simon Josefsson To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> <20051022191543.8424F11425@sa.vix.com> 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 Date: Mon, 24 Oct 2005 15:44:33 +0200 In-Reply-To: <20051022191543.8424F11425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 19:15:43 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Mon Oct 24 09:51:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2jB-0001HI-IX for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:51:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10739 for ; Mon, 24 Oct 2005 09:50:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU2hv-0002HO-Gf for namedroppers-data@psg.com; Mon, 24 Oct 2005 13:49:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU2hm-0002GT-Jw for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 13:49:38 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9ODnNq5010516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2005 15:49:24 +0200 From: Simon Josefsson To: Chris Thompson Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> 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 Date: Mon, 24 Oct 2005 15:49:22 +0200 In-Reply-To: (Chris Thompson's message of "Mon, 24 Oct 2005 13:12:35 +0100 (BST)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Mon Oct 24 10:30:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3L0-0003g6-EI for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 10:30:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12717 for ; Mon, 24 Oct 2005 10:29:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU3Hk-0004T0-6L for namedroppers-data@psg.com; Mon, 24 Oct 2005 14:26:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU3Hj-0004Sm-5S for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 14:26:47 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 14CE633C1B; Mon, 24 Oct 2005 15:26:45 +0100 (BST) Message-ID: <435CEF2C.10105@algroup.co.uk> Date: Mon, 24 Oct 2005 15:26:52 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Peter Koch CC: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 11:01:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3on-0004Mx-Gj for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 11:01:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14146 for ; Mon, 24 Oct 2005 11:00:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU3kq-0006EE-Cc for namedroppers-data@psg.com; Mon, 24 Oct 2005 14:56:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EU3kk-0006Dy-BJ for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 14:56:46 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 16:56:43 +0200 Date: Mon, 24 Oct 2005 16:56:43 +0200 (CEST) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Peter Koch cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 24 12:39:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Lx-0002aa-Ek for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 12:39:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19446 for ; Mon, 24 Oct 2005 12:39:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU5GE-000CGB-4h for namedroppers-data@psg.com; Mon, 24 Oct 2005 16:33:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU5GD-000CFs-KQ for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 16:33:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C39AE11425; Mon, 24 Oct 2005 16:33:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: Peter Koch , namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Mon, 24 Oct 2005 13:56:20 +0200." <20051024115620.GB24941@outpost.ds9a.nl> References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> Date: Mon, 24 Oct 2005 16:33:20 +0000 Message-Id: <20051024163320.C39AE11425@sa.vix.com> 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 Mon Oct 24 13:02:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5iF-0001w3-N7 for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:02:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20747 for ; Mon, 24 Oct 2005 13:02:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU5er-000DwV-CF for namedroppers-data@psg.com; Mon, 24 Oct 2005 16:58:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU5eq-000DwK-Oj for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 16:58:48 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 24 Oct 2005 12:58:47 -0400 id 005D40B6.435D12C7.0000026C 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> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 12:58:50 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 13:07:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5nQ-00051U-Ez for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:07:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21046 for ; Mon, 24 Oct 2005 13:07:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU5kX-000EM1-HS for namedroppers-data@psg.com; Mon, 24 Oct 2005 17:04:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EU5kW-000ELp-St for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 17:04:41 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 30067C2DA8; Mon, 24 Oct 2005 18:04:39 +0100 (BST) Date: Mon, 24 Oct 2005 18:04:26 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , bert hubert Cc: Peter Koch , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Message-ID: <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> 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> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 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 Mon Oct 24 13:16:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5vb-0007Wd-Pi for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:16:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21394 for ; Mon, 24 Oct 2005 13:15:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU5t2-000F1b-FB for namedroppers-data@psg.com; Mon, 24 Oct 2005 17:13:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU5t1-000F1M-R4 for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 17:13:27 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2E15B56904; Mon, 24 Oct 2005 10:13:26 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20051024125920.05e40e60@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 24 Oct 2005 13:14:00 -0400 To: Paul Vixie , bert hubert From: Mike StJohns Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Cc: Peter Koch , namedroppers@ops.ietf.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Mon Oct 24 13:17:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5we-0007z5-Jw for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:17:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21445 for ; Mon, 24 Oct 2005 13:16:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU5uE-000F6X-LY for namedroppers-data@psg.com; Mon, 24 Oct 2005 17:14:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU5uE-000F6D-7D for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 17:14:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CEA4411426 for ; Mon, 24 Oct 2005 17:14:41 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: DNSEXT WG Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Mon, 24 Oct 2005 12:58:50 -0400." References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> Date: Mon, 24 Oct 2005 17:14:41 +0000 Message-Id: <20051024171441.CEA4411426@sa.vix.com> 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 Mon Oct 24 13:23:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU62d-0000bc-A7 for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:23:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21738 for ; Mon, 24 Oct 2005 13:23:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU605-000Fe4-HK for namedroppers-data@psg.com; Mon, 24 Oct 2005 17:20:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU605-000Fdt-2w for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 17:20:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AE8E511425 for ; Mon, 24 Oct 2005 17:20:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Mon, 24 Oct 2005 18:04:26 +0100." <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> 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]> Date: Mon, 24 Oct 2005 17:20:44 +0000 Message-Id: <20051024172044.AE8E511425@sa.vix.com> 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 Mon Oct 24 13:26:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU65l-00014x-II for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:26:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21876 for ; Mon, 24 Oct 2005 13:26:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU63U-000FxK-97 for namedroppers-data@psg.com; Mon, 24 Oct 2005 17:24:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU63T-000Fx5-Qb for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 17:24:15 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 63C9511425; Mon, 24 Oct 2005 17:24:15 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mike StJohns cc: bert hubert , Peter Koch , namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Mon, 24 Oct 2005 13:14:00 -0400." <6.2.1.2.2.20051024125920.05e40e60@localhost> 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> Date: Mon, 24 Oct 2005 17:24:15 +0000 Message-Id: <20051024172415.63C9511425@sa.vix.com> 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 Mon Oct 24 14:16:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6rd-00013h-Ko for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 14:16:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24323 for ; Mon, 24 Oct 2005 14:15:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU6o3-000J6c-IQ for namedroppers-data@psg.com; Mon, 24 Oct 2005 18:12:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU6o2-000J6O-TI for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 18:12:22 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 24 Oct 2005 14:12:21 -0400 id 005D408F.435D2405.00001216 In-Reply-To: <20051024172044.AE8E511425@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> <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 Message-Id: <8216CDE1-D8FE-4EBA-9FD8-22285AD9181F@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 14:12:24 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 14:18:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6u8-0001W4-Dd for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 14:18:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24432 for ; Mon, 24 Oct 2005 14:18:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU6rK-000JKx-RG for namedroppers-data@psg.com; Mon, 24 Oct 2005 18:15:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU6rK-000JKl-92 for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 18:15:46 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DBB1C11425 for ; Mon, 24 Oct 2005 18:15:45 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Your message of "Mon, 24 Oct 2005 14:12:24 -0400." <8216CDE1-D8FE-4EBA-9FD8-22285AD9181F@verisignlabs.com> 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> Date: Mon, 24 Oct 2005 18:15:45 +0000 Message-Id: <20051024181545.DBB1C11425@sa.vix.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 Mon Oct 24 14:18:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6uC-0001WP-CH for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 14:18:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24444 for ; Mon, 24 Oct 2005 14:18:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU6rm-000JNT-Kk for namedroppers-data@psg.com; Mon, 24 Oct 2005 18:16:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU6rm-000JMl-2C for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 18:16:14 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 24 Oct 2005 14:16:13 -0400 id 005D408F.435D24ED.00001302 In-Reply-To: <20051024171441.CEA4411426@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> <20051024171441.CEA4411426@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 14:16:16 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 24 14:33:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU78G-00067i-Pf for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 14:33:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25162 for ; Mon, 24 Oct 2005 14:33:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU75M-000KdS-4P for namedroppers-data@psg.com; Mon, 24 Oct 2005 18:30:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU75J-000KbO-An for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 18:30:13 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 37DD92B6 for ; Mon, 24 Oct 2005 14:30:12 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7783841B7 for ; Mon, 24 Oct 2005 14:30:11 -0400 (EDT) Date: Mon, 24 Oct 2005 14:30:11 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051024183011.7783841B7@thrintun.hactrn.net> 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 Mon Oct 24 16:02:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8WD-00077h-49 for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 16:02:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01149 for ; Mon, 24 Oct 2005 16:01:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EU8Rx-0000Q0-Dj for namedroppers-data@psg.com; Mon, 24 Oct 2005 19:57:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EU8Rw-0000Pm-9w for namedroppers@ops.ietf.org; Mon, 24 Oct 2005 19:57:40 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9OJvYOj081240; Mon, 24 Oct 2005 21:57:34 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20051024172044.AE8E511425@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> <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" Message-Id: <690B066F-42FC-4D3E-9365-882CC626CD8B@NLnetLabs.nl> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 21:57:21 +0200 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 steve.ballhomes@nysportsfans.com Mon Oct 24 20:49:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUD03-0007CQ-5k for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 20:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08234 for ; Mon, 24 Oct 2005 20:48:56 -0400 (EDT) Received: from [211.90.77.186] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUDCp-0007vd-OT for dnsext-archive@ietf.org; Mon, 24 Oct 2005 21:02:28 -0400 Message-ID: <000001c5d8fc$a9ad6b00$0100007f@localhost> From: "Camron Alexander" To: Subject: Stop throwing away your money Date: Tue, 25 Oct 2005 00:48:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5D8FC.A9AD6B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5D8FC.A9AD6B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5D8FC.A9AD6B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

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

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

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

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5D8FC.A9AD6B00-- From DarleneRubin@fiveminuteflorist.net Mon Oct 24 22:26:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEWL-0005h0-Mw for dnsext-archive@megatron.ietf.org; Mon, 24 Oct 2005 22:26:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11751 for ; Mon, 24 Oct 2005 22:26:22 -0400 (EDT) Received: from cm218-252-147-38.hkcable.com.hk ([218.252.147.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUEjC-0001Q7-5D for dnsext-archive@ietf.org; Mon, 24 Oct 2005 22:39:55 -0400 Received: from 6tKf@localhost by fDUV.int (8.11.6/8.11.6); Mon, 24 Oct 2005 22:22:39 -0500 Message-ID: From: "Vera Hatch" Reply-To: "Vera Hatch" To: dnsext-archive@ietf.org, nona.dwyer@ietf.org Subject: Adobe software for 80 % 0ff Date: Tue, 25 Oct 2005 02:22:39 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DarleneRubin@fiveminuteflorist.net Content-Type: multipart/mixed; boundary="--yk5XpiQP9zfoSJni3z" X-Spam-Score: 2.8 (++) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 pXHK ----yk5XpiQP9zfoSJni3z Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Y
Opt-in Email Special Offer   = ;  unsubscribe me

<= td vAlign=3Dbottom> SEARCH
<= /tr>

<= b> TOP 10 NE= W TITLES
<= /tr>  = Adobe Illustrator 11= Customers also bought

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
4= Adobe Acrobat 7 Pro
5= Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10
  See more by this manufacturer
   Microsoft
=    Symantec<= /a>
   Adobe
 
&n= bsp;  these other items= ..

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT downlo= ad!
Coupon Code: nKQ6GCO
 

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

List Price:$499.00
Price:$69.99
$429.01 (86%)
<= td width=3D100% height=3D55>

Adobe Photoshop CS2 V 9.0
Adobe

Choose:=
=  

List Price:$599.00
Price:$69.99
You Save:<= /td>$529.01 (= 90%)



Availability: = Available for INSTANT download!
Coupon Code: sNDyEx
 <= /p>

Sales Rank: #2
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
<= font class=3Dtiny>Average Customer Review:3D"5= Based on 1523 re= views. Write a review.

Microsoft Windows XP Professional or Longhorn Edition
= Microsoft

=
Choose:
&nbs= p;

List Price:$279.00
Price:$49.99
You Save:$229.0= 1 (85%)



Availability: Available for INSTANT download!
Coupon Code: F5dtP0jOw
&= nbsp;

Sales Rank: #3
System requirements&= nbsp; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review: Based on 1= 8989 reviews. Write a review.<= /p>

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
<= a href=3Dhttp://ezsoftdl.net/?2>  <= /td>

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



Availability: Available for IN= STANT download!
Coupon Code: mW8FhC
 

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

----yk5XpiQP9zfoSJni3z-- From owner-namedroppers@ops.ietf.org Tue Oct 25 14:42:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTkS-0003M4-Ve for dnsext-archive@megatron.ietf.org; Tue, 25 Oct 2005 14:42:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11726 for ; Tue, 25 Oct 2005 14:41:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUTfN-000CMf-DJ for namedroppers-data@psg.com; Tue, 25 Oct 2005 18:36:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUTfM-000CMP-Jk for namedroppers@ops.ietf.org; Tue, 25 Oct 2005 18:36:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9PIWWbD009401 for ; Tue, 25 Oct 2005 14:32:32 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAApRaOvs; Tue, 25 Oct 05 14:32:24 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9PIYDN2018999; Tue, 25 Oct 2005 14:34:20 -0400 (EDT) Date: Tue, 25 Oct 2005 14:34:13 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism In-Reply-To: <434ECAB8.8030600@algroup.co.uk> Message-ID: References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed Oct 26 04:23:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgZL-0005Wh-Ug for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 04:23:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03225 for ; Wed, 26 Oct 2005 04:23:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUgV1-000Bxm-Ru for namedroppers-data@psg.com; Wed, 26 Oct 2005 08:19:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUgV0-000BxY-Ny for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 08:19:07 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9Q8Itr6003651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Oct 2005 10:18:56 +0200 From: Simon Josefsson To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Ben Laurie Subject: Re: NSEC3 signalling mechanism References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> 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 Date: Wed, 26 Oct 2005 10:18:54 +0200 In-Reply-To: (Samuel Weiler's message of "Tue, 25 Oct 2005 14:34:13 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Wed Oct 26 04:50:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgzN-0003Ai-P7 for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 04:50:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04779 for ; Wed, 26 Oct 2005 04:50:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUgwh-000Dbs-GD for namedroppers-data@psg.com; Wed, 26 Oct 2005 08:47:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUgwf-000Dbg-CS for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 08:47:41 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2E36A44C1; Wed, 26 Oct 2005 10:47:39 +0200 (CEST) Date: Wed, 26 Oct 2005 10:47:38 +0200 From: bert hubert To: Simon Josefsson Cc: Samuel Weiler , namedroppers@ops.ietf.org, Ben Laurie Subject: Re: NSEC3 signalling mechanism Message-ID: <20051026084738.GB11735@outpost.ds9a.nl> References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 dominicdqej@blackjelly.com Wed Oct 26 06:34:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUibn-0006Av-8V for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 06:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10325 for ; Wed, 26 Oct 2005 06:33:58 -0400 (EDT) Received: from cku208.neoplus.adsl.tpnet.pl ([83.31.96.208] helo=83.31.96.208) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUios-0004gZ-F0 for dnsext-archive@ietf.org; Wed, 26 Oct 2005 06:47:50 -0400 Received: from blackjelly.com by 83.31.96.208 (8.9.3/8.9.3) with ESMTP id uY62tFkmD8Jd for ; Wed, 26 Oct 2005 05:41:27 -0400 Received: from yhviinrayqhg (HELO ytbaon) ([197.15.133.125]) by blackjelly.com with ESMTP for ; Wed, 26 Oct 2005 05:41:27 -0400 Date: Wed, 26 Oct 2005 05:41:27 -0400 From: Eleanor Bowman Reply-To: Eleanor Bowman Message-ID: <573120844884.048606837088@blackjelly.com> To: Subject: 0nline software, Download Symantec, Adobe, Windows & others Instantly MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit oin
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES
 

 ON SALE NOW!

 1 Office Pr! o Edition 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
 4 Systemworks Pro 2004 Edition
 5 Flash MX 2004
 6 Corel Painter 8< /tr>
 7 Adobe Acrobat 6.0
 8 Windows 2003 Server
 9 Alias Maya 6.0 Wavefront
 10 Adobe Premiere
  See more by this manufacturer
  Microsoft
   Apple Software
  Customers also bought
   these other items...



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:$899.00
Price:$69.99
You Save:$830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and man age business information using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon Expires: May 30th, 2005
Average Customer Review: 5 out of 5 stars Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-! ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Coupon Expires: May 30th, 2005
Average Custome! r Review: 5 out of 5 stars Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price: $1149.00
Price:$99.99
You Save:$849.01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolset
  • Single installer--control what you install and when you install it
  • Cross-media publishing--create content for bot! h print and the Web

Sales Rank: #3
Shipping: International/US or via instant download
Date Coupon Expires: May 30th, 2005
Average Customer Review: 5 out of 5 stars Based on 498 reviews. Write a review.

From owner-namedroppers@ops.ietf.org Wed Oct 26 07:11:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjBO-0007SY-Ts for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 07:11:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11958 for ; Wed, 26 Oct 2005 07:10:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUj8o-000LaH-S6 for namedroppers-data@psg.com; Wed, 26 Oct 2005 11:08:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUj8l-000LZy-1q for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 11:08:19 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8B0D233C1A; Wed, 26 Oct 2005 12:08:17 +0100 (BST) Message-ID: <435F63A2.30205@algroup.co.uk> Date: Wed, 26 Oct 2005 12:08:18 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 116qtk63v2i4528@kassarol.com Wed Oct 26 09:34:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlPz-0002sG-ME for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 09:34:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19699 for ; Wed, 26 Oct 2005 09:34:00 -0400 (EDT) Received: from [201.236.1.183] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUld9-0001kT-GL for dnsext-archive@ietf.org; Wed, 26 Oct 2005 09:47:52 -0400 Message-ID: <000001c5da30$aca97800$0100007f@localhost> From: "Wyatt Washington" <116qtk63v2i4528@kassarol.com> To: Subject: Buy OEM Software Date: Wed, 26 Oct 2005 13:33:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DA30.ACA97800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DA30.ACA97800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5DA30.ACA97800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5DA30.ACA97800-- From owner-namedroppers@ops.ietf.org Wed Oct 26 10:45:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmXC-0007Im-Ss for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:45:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24285 for ; Wed, 26 Oct 2005 10:45:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUmTb-0009wU-FR for namedroppers-data@psg.com; Wed, 26 Oct 2005 14:42:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EUmTa-0009w3-BQ for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 14:42:02 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9QEfxcw021422 for ; Wed, 26 Oct 2005 16:42:00 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9QEfxr21556 for ; Wed, 26 Oct 2005 16:41:59 +0200 (MEST) Message-Id: <200510261441.j9QEfxr21556@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-reply-to: Your message of "Mon, 24 Oct 2005 16:56:43 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Date: Wed, 26 Oct 2005 16:41:59 +0200 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 Wed Oct 26 10:52:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmdU-0002ww-Kt for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:52:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24832 for ; Wed, 26 Oct 2005 10:52:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUmbO-000AUv-Fy for namedroppers-data@psg.com; Wed, 26 Oct 2005 14:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUmbN-000ATp-Cg for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 14:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUmbJ-0003Vy-Sb; Wed, 26 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec3-03.txt Message-Id: Date: Wed, 26 Oct 2005 10:50:01 -0400 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 Wed Oct 26 11:16:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn14-0004BM-E4 for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:16:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00312 for ; Wed, 26 Oct 2005 11:16:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUmys-000C5l-LD for namedroppers-data@psg.com; Wed, 26 Oct 2005 15:14:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUmys-000C5Z-0S for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 15:14:22 +0000 Received: from monsoon.verisignlabs.com ([::ffff:172.25.170.10]) by mail.verisignlabs.com with esmtp; Wed, 26 Oct 2005 11:14:20 -0400 id 005D4108.435F9D4C.0000731A Received: by monsoon.verisignlabs.com (Postfix, from userid 1000) id 6AAE9137E86; Wed, 26 Oct 2005 11:14:20 -0400 (EDT) Date: Wed, 26 Oct 2005 11:14:20 -0400 From: Matt Larson To: Ben Laurie Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism Message-ID: <20051026151420.GC15889@monsoon.verisignlabs.com> 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 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 Content-Transfer-Encoding: 7bit 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 Wed Oct 26 11:27:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnBc-0002xS-Ip for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:27:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01186 for ; Wed, 26 Oct 2005 11:27:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUnA3-000Cu3-Gz for namedroppers-data@psg.com; Wed, 26 Oct 2005 15:25:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUnA2-000Ctl-Q5 for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 15:25:54 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Wed, 26 Oct 2005 11:25:53 -0400 id 005D4268.435FA001.000078F7 In-Reply-To: <200510261441.j9QEfxr21556@tyrannia.TechFak.Uni-Bielefeld.DE> 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 Message-Id: <640B4E6D-C545-4E39-A511-F80492B58AAD@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Wed, 26 Oct 2005 11:25:51 -0400 To: Peter Koch X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Wed Oct 26 11:27:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnC0-0003aB-6L for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:27:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01223 for ; Wed, 26 Oct 2005 11:27:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUnAO-000CvP-SW for namedroppers-data@psg.com; Wed, 26 Oct 2005 15:26:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUnAO-000CvC-C2 for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 15:26:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E611211426; Wed, 26 Oct 2005 15:26:15 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ben Laurie cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism In-Reply-To: Your message of "Wed, 26 Oct 2005 12:08:18 +0100." <435F63A2.30205@algroup.co.uk> References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> Date: Wed, 26 Oct 2005 15:26:15 +0000 Message-Id: <20051026152615.E611211426@sa.vix.com> 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 Wed Oct 26 12:31:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoBd-0002rm-BT for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 12:31:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05949 for ; Wed, 26 Oct 2005 12:31:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUo97-000H4I-OU for namedroppers-data@psg.com; Wed, 26 Oct 2005 16:29:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUo95-000H3x-06 for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 16:28:59 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9QGSho2013480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Oct 2005 18:28:44 +0200 From: Simon Josefsson To: Paul Vixie Cc: Samuel Weiler , namedroppers@ops.ietf.org, Ben Laurie Subject: Re: NSEC3 signalling mechanism References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> <20051026152615.E611211426@sa.vix.com> 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 Date: Wed, 26 Oct 2005 18:28:41 +0200 In-Reply-To: <20051026152615.E611211426@sa.vix.com> (Paul Vixie's message of "Wed, 26 Oct 2005 15:26:15 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 alexander@domainscash.com Wed Oct 26 14:15:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpo8-0001Hc-5a for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 14:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11414 for ; Wed, 26 Oct 2005 14:15:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUq1L-00042x-Cd for dnsext-archive@ietf.org; Wed, 26 Oct 2005 14:29:07 -0400 Received: from afz170.internetdsl.tpnet.pl ([83.16.155.170] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EUpo7-0007mV-Ko for dnsext-archive@ietf.org; Wed, 26 Oct 2005 14:15:28 -0400 Date: r, 26 pa 2005 20:15:18 +0100 From: "Hersch" To: Subject: Don't expose your intimate life! Message-ID: <000601c5d9ab$6f1a5980$795bcf52@wdewk> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html X-Spam-Score: 3.1 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

Suffering from pain, depression or heartburn? We'll help you!
  • Need some love pi11s?
  • So, why go to your local dr@gstore?
  • Why waste time and extra money?
  • Why let people know about your intimate life?
  • Evil-wishers are always around to spread rumors. We give you the issue!
Our store is VERIFIED BY BBB! All transactions are APPROVED BY VISA!
 From owner-namedroppers@ops.ietf.org Wed Oct 26 15:35:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUr3Y-0005Cd-Px for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:35:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17040 for ; Wed, 26 Oct 2005 15:35:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUqy7-0002lw-FP for namedroppers-data@psg.com; Wed, 26 Oct 2005 19:29:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUqy3-0002le-T4 for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 19:29:48 +0000 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1EUqxx-0007LP-8A; Wed, 26 Oct 2005 21:29:41 +0200 Received: from localhost by mail-int1.denic.de with local id 1EUqxr-0003an-00; Wed, 26 Oct 2005 21:29:35 +0200 Date: Wed, 26 Oct 2005 21:29:35 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Message-ID: <20051026192935.GW16044@denics7.denic.de> 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 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 owner-namedroppers@ops.ietf.org Wed Oct 26 15:53:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrKh-0006MU-Bl for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:53:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18249 for ; Wed, 26 Oct 2005 15:52:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUrHm-0004PR-Lz for namedroppers-data@psg.com; Wed, 26 Oct 2005 19:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUrHj-0004Ok-18 for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 19:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHe-00071Z-JA; Wed, 26 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-08.txt Message-Id: Date: Wed, 26 Oct 2005 15:50:02 -0400 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 Wed Oct 26 15:53:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrKk-0006NY-T3 for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:53:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18250 for ; Wed, 26 Oct 2005 15:52:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUrI4-0004Rh-1c for namedroppers-data@psg.com; Wed, 26 Oct 2005 19:50:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUrI0-0004Qw-Dj for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 19:50:24 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHe-00071t-NO; Wed, 26 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-05.txt Message-Id: Date: Wed, 26 Oct 2005 15:50:02 -0400 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 : 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-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 26 15:53:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrKv-0006Pv-C7 for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:53:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18302 for ; Wed, 26 Oct 2005 15:53:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUrIa-0004Vd-Ir for namedroppers-data@psg.com; Wed, 26 Oct 2005 19:51:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUrIO-0004Uw-TS for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 19:50:49 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHf-00072q-31; Wed, 26 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-08.txt Message-Id: Date: Wed, 26 Oct 2005 15:50:03 -0400 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 Wed Oct 26 15:54:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrLe-0006g8-JZ for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:54:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18538 for ; Wed, 26 Oct 2005 15:53:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUrJF-0004ag-2L for namedroppers-data@psg.com; Wed, 26 Oct 2005 19:51:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUrJB-0004aM-DF for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 19:51:37 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHf-00074S-N6; Wed, 26 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-02.txt Message-Id: Date: Wed, 26 Oct 2005 15:50:03 -0400 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 Wed Oct 26 17:05:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsT2-0000dP-Hv for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:05:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23468 for ; Wed, 26 Oct 2005 17:05:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUsPk-000ABV-30 for namedroppers-data@psg.com; Wed, 26 Oct 2005 21:02:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUsPf-000AB7-Gu for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 21:02:24 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 522DA33C1A; Wed, 26 Oct 2005 22:02:17 +0100 (BST) Message-ID: <435FEEDA.7080804@algroup.co.uk> Date: Wed, 26 Oct 2005 22:02:18 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Paul Vixie CC: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> <20051026152615.E611211426@sa.vix.com> In-Reply-To: <20051026152615.E611211426@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # > 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 Wed Oct 26 17:30:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsr6-0007u7-DH for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:30:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27918 for ; Wed, 26 Oct 2005 17:30:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUsom-000CDF-3C for namedroppers-data@psg.com; Wed, 26 Oct 2005 21:28:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUsok-000CD2-Ek for namedroppers@ops.ietf.org; Wed, 26 Oct 2005 21:28:19 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9QLNrTJ016567 for ; Wed, 26 Oct 2005 17:23:53 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAY_aavG; Wed, 26 Oct 05 17:23:47 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9QKvFS8015220; Wed, 26 Oct 2005 16:57:15 -0400 (EDT) Date: Wed, 26 Oct 2005 16:57:15 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 In-Reply-To: <6.2.3.4.2.20050901145800.04065900@localhost> Message-ID: 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tislabs.com id j9QKvFS8015220 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable 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 herman.bollers@permanent-daylight.net Wed Oct 26 21:56:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUx04-0000ix-5g for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 21:56:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15088 for ; Wed, 26 Oct 2005 21:56:00 -0400 (EDT) Received: from [61.242.151.197] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUxDK-0002ml-BC for dnsext-archive@ietf.org; Wed, 26 Oct 2005 22:09:59 -0400 Message-ID: <000001c5da98$769fde80$0100007f@localhost> From: "Dillon Russell" To: Subject: cheap oem soft shipping //orldwide Date: Thu, 27 Oct 2005 01:56:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DA98.769FDE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DA98.769FDE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5DA98.769FDE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!

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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5DA98.769FDE80-- From owner-namedroppers@ops.ietf.org Wed Oct 26 22:35:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUxbl-00052A-UP for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 22:35:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16683 for ; Wed, 26 Oct 2005 22:34:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUxXP-0005NH-E9 for namedroppers-data@psg.com; Thu, 27 Oct 2005 02:30:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUxXO-0005N4-Kb for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 02:30:42 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9R2UV7T043740; Wed, 26 Oct 2005 22:30:32 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051026214714.03844950@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 26 Oct 2005 22:30:30 -0400 To: Samuel Weiler , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Cc: namedroppers@ops.ietf.org In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 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 Wed Oct 26 23:53:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyp2-0001Li-J2 for dnsext-archive@megatron.ietf.org; Wed, 26 Oct 2005 23:53:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20457 for ; Wed, 26 Oct 2005 23:52:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUymW-000Aie-1L for namedroppers-data@psg.com; Thu, 27 Oct 2005 03:50:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUymV-000AiQ-1h for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 03:50:23 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9R3o4TU043980; Wed, 26 Oct 2005 23:50:05 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051020094011.03be1a98@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 26 Oct 2005 23:49:38 -0400 To: Margaret Wasserman From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Document Advancement: TSIG/SHA1 for DS Cc: "Olaf M. Kolkman" , Mark Townsley , ogud@ogud.com, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Thu Oct 27 00:20:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUzFT-0002wx-PA for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 00:20:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21426 for ; Thu, 27 Oct 2005 00:20:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUzDg-000CSH-Mg for namedroppers-data@psg.com; Thu, 27 Oct 2005 04:18:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUzDd-000CS5-JQ for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 04:18:26 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j9R4ICpN044104 for ; Thu, 27 Oct 2005 00:18:12 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051027001221.03f0a480@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Oct 2005 00:18:08 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: IETF-64 DNSEXT Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As 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 Thu Oct 27 02:13:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV11L-0000dX-NS for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 02:13:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26654 for ; Thu, 27 Oct 2005 02:13:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV0y9-000JAk-AA for namedroppers-data@psg.com; Thu, 27 Oct 2005 06:10:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV0y8-000JAV-BU for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 06:10:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9R6682M005575 for ; Thu, 27 Oct 2005 02:06:08 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgKaW3k; Thu, 27 Oct 05 02:06:04 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9R67pNK002090; Thu, 27 Oct 2005 02:07:52 -0400 (EDT) Date: Thu, 27 Oct 2005 02:07:51 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC2536bis and RFC2539bis In-Reply-To: <6.2.3.4.2.20051017155946.03fbdd88@localhost> Message-ID: References: <6.2.3.4.2.20051017155946.03fbdd88@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu Oct 27 08:31:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6uO-0006EQ-KR for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 08:31:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26008 for ; Thu, 27 Oct 2005 08:30:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV6rk-000D5F-MQ for namedroppers-data@psg.com; Thu, 27 Oct 2005 12:28:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV6rg-000D51-Op for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 12:28:16 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j9RCaQQ6017938 for ; Thu, 27 Oct 2005 05:36:27 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9RCZf7u012950 for ; Thu, 27 Oct 2005 07:35:42 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Oct 2005 08:28:10 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810B5A5952@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-ecc-key-08.txt Date: Thu, 27 Oct 2005 08:28:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Thu Oct 27 08:32:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6vN-0006n8-5X for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 08:32:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26026 for ; Thu, 27 Oct 2005 08:31:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV6pS-000CzQ-2R for namedroppers-data@psg.com; Thu, 27 Oct 2005 12:25:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV6pM-000Cyw-Lk for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 12:25:52 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9RCbopc016907 for ; Thu, 27 Oct 2005 05:37:50 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9RCZwNP022241 for ; Thu, 27 Oct 2005 07:35:58 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Oct 2005 08:25:50 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810B5A594D@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-tsig-sha-05.txt Date: Thu, 27 Oct 2005 08:25:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Thu Oct 27 10:54:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV99N-0004s8-Gb for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 10:54:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04661 for ; Thu, 27 Oct 2005 10:54:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV94w-000LdH-Rf for namedroppers-data@psg.com; Thu, 27 Oct 2005 14:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EV94s-000Lbx-VM for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 14:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94r-0000Gh-S7; Thu, 27 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-03.txt Message-Id: Date: Thu, 27 Oct 2005 10:50:01 -0400 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 Thu Oct 27 11:16:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9Ur-0007Af-HH for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 11:16:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12016 for ; Thu, 27 Oct 2005 11:16:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV9So-000NTg-GP for namedroppers-data@psg.com; Thu, 27 Oct 2005 15:14:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EV9Sk-000NTO-2A for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 15:14:42 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9RFEe5i000821 for ; Thu, 27 Oct 2005 17:14:40 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9RFEd804182 for ; Thu, 27 Oct 2005 17:14:39 +0200 (MEST) Message-Id: <200510271514.j9RFEd804182@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-03.txt In-reply-to: Message of "Thu, 27 Oct 2005 10:50:01 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4175.1130426072.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Thu, 27 Oct 2005 17:14:39 +0200 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 Thu Oct 27 15:55:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDqY-0000Q7-V4 for dnsext-archive@megatron.ietf.org; Thu, 27 Oct 2005 15:55:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26018 for ; Thu, 27 Oct 2005 15:55:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVDlI-000EeX-7v for namedroppers-data@psg.com; Thu, 27 Oct 2005 19:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVDlH-000EeI-Dc for namedroppers@ops.ietf.org; Thu, 27 Oct 2005 19:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlD-0006Qa-0H; Thu, 27 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-trustupdate-threshold-01.txt Message-Id: Date: Thu, 27 Oct 2005 15:50:03 -0400 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 Oct 28 00:14:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVLdn-0008Hi-LV for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 00:14:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17939 for ; Fri, 28 Oct 2005 00:14:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVLYc-000HKy-PS for namedroppers-data@psg.com; Fri, 28 Oct 2005 04:09:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVLYc-000HKn-8K for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 04:09:34 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 55620677FE for ; Fri, 28 Oct 2005 04:09:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id j9S49RnW047120 for ; Fri, 28 Oct 2005 14:09:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200510280409.j9S49RnW047120@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: IETF-64 DNSEXT Agenda In-reply-to: Your message of "Thu, 27 Oct 2005 00:18:08 -0400." <6.2.5.6.2.20051027001221.03f0a480@ogud.com> Date: Fri, 28 Oct 2005 14:09:27 +1000 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 Oct 28 12:20:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWyP-00084f-5Z for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:20:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27241 for ; Fri, 28 Oct 2005 12:20:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVWux-000Db8-OK for namedroppers-data@psg.com; Fri, 28 Oct 2005 16:17:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EVWuw-000DaV-I1 for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 16:17:22 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j9SGHJ0M011361 for ; Fri, 28 Oct 2005 18:17:20 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j9SGHJm17042 for ; Fri, 28 Oct 2005 18:17:19 +0200 (MEST) Message-Id: <200510281617.j9SGHJm17042@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: WGLC: Name Server Identifier Option In-reply-to: Your message of "Tue, 11 Oct 2005 15:03:14 EDT." <20051011190314.629FE41A7@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17037.1130516235.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Fri, 28 Oct 2005 18:17:19 +0200 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 Oct 28 12:21:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWyT-00084y-6i for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:21:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27249 for ; Fri, 28 Oct 2005 12:20:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVWtx-000DUb-Mv for namedroppers-data@psg.com; Fri, 28 Oct 2005 16:16:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVWtw-000DUP-Uw for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 16:16:21 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 28 Oct 2005 12:16:19 -0400 id 005D434D.43624ED3.0000051C Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_cliffie-1308-1130516179-0001-2" X-Gpgmail-State: !signed Message-Id: To: DNSEXT WG From: David Blacka Subject: NSEC3 pilot Date: Fri, 28 Oct 2005 12:16:18 -0400 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 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 Oct 28 13:30:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVY2E-0005lf-RP for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:29:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29595 for ; Fri, 28 Oct 2005 13:28:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVXzX-000I65-HQ for namedroppers-data@psg.com; Fri, 28 Oct 2005 17:26:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVXzU-000I5r-PE for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 17:26:09 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9SHPxxs057543; Fri, 28 Oct 2005 19:26:00 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: 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" Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 signalling mechanism Date: Fri, 28 Oct 2005 10:25:58 -0700 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 Oct 28 14:13:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYjA-0007XR-CT for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:13:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01546 for ; Fri, 28 Oct 2005 14:13:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVYhJ-000Kr8-Fu for namedroppers-data@psg.com; Fri, 28 Oct 2005 18:11:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVYhI-000Kqv-Fj for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 18:11:24 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9SI70gt007084 for ; Fri, 28 Oct 2005 14:07:00 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUlai1n; Fri, 28 Oct 05 14:06:57 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9SI8xJk009173 for ; Fri, 28 Oct 2005 14:08:59 -0400 (EDT) Date: Fri, 28 Oct 2005 14:08:59 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Namedroppers Subject: NSEC3 design FAQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Oct 28 17:42:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbzO-0000Ah-GX for dnsext-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:42:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21612 for ; Fri, 28 Oct 2005 17:42:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVbv9-0007Gu-Vd for namedroppers-data@psg.com; Fri, 28 Oct 2005 21:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVbv8-0007Ge-UB for namedroppers@ops.ietf.org; Fri, 28 Oct 2005 21:37:55 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0026CB; 28 Oct 2005 17:42:54 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 28 Oct 2005 17:42:39 -0400 Received: from connotech.com (209.71.204.101) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0026CA; 28 Oct 2005 17:42:31 -0400 Message-ID: <4362A1E4.40505@connotech.com> Date: Fri, 28 Oct 2005 18:10:44 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers , dnssec-deployment@shinkuro.com Subject: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: 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 Sat Oct 29 01:30:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVjIX-0007G6-VD for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 01:30:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12100 for ; Sat, 29 Oct 2005 01:30:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVjEB-0005w8-7y for namedroppers-data@psg.com; Sat, 29 Oct 2005 05:26:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVjEA-0005vw-Nm for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 05:26:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 36B8E11459; Sat, 29 Oct 2005 05:26:02 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Thierry Moreau cc: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM In-Reply-To: Your message of "Fri, 28 Oct 2005 18:10:44 -0400." <4362A1E4.40505@connotech.com> References: <4362A1E4.40505@connotech.com> Date: Sat, 29 Oct 2005 05:26:02 +0000 Message-Id: <20051029052602.36B8E11459@sa.vix.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 Sat Oct 29 02:21:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVk65-0002ni-J0 for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 02:21:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14003 for ; Sat, 29 Oct 2005 02:21:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVk32-00086I-L1 for namedroppers-data@psg.com; Sat, 29 Oct 2005 06:18:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVk2x-000862-UK for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 06:18:32 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j9T6IOSM005474; Fri, 28 Oct 2005 23:18:24 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j9T6INiQ005471; Fri, 28 Oct 2005 23:18:24 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 28 Oct 2005 23:18:23 -0700 (PDT) From: "william(at)elan.net" To: Paul Vixie cc: Thierry Moreau , Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM In-Reply-To: <20051029052602.36B8E11459@sa.vix.com> Message-ID: References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 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 VivianReyna@cossettepostal.com Sat Oct 29 06:57:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVoOf-00021B-9z for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 06:57:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24373 for ; Sat, 29 Oct 2005 06:56:55 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVocQ-0007ud-4Z for dnsext-archive@ietf.org; Sat, 29 Oct 2005 07:11:26 -0400 Received: from [218.149.66.2] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EVoOY-00057v-Rj for dnsext-archive@ietf.org; Sat, 29 Oct 2005 06:57:07 -0400 Received: from dJzS@localhost by H8pU.int (8.11.6/8.11.6); Sat, 29 Oct 2005 07:04:42 -0200 Message-ID: From: "Sarah Self" Reply-To: "Sarah Self" To: dnsext-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Systemworks Date: Sat, 29 Oct 2005 13:12:42 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VivianReyna@cossettepostal.com Content-Type: multipart/mixed; boundary="--f8dVkmeRA4SybqKFY6E5" X-Spam-Score: 3.6 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 bD2 ----f8dVkmeRA4SybqKFY6E5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable H
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

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

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

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

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



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

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

Adobe Creative Suite 2 *Premi= um*
Adobe=

Choose:
 

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

=

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

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

=

Microsoft Of= fice 2003 *Professional*
Microsoft

=
Choose= :
 

<= /p>

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

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

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

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

Adobe Acrobat Professional V 7.0
= Adobe

<= tr>
Choose:
=  

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

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

Availabilit= y: Available for INSTANT download!
Coupon Code: AWLvr4c
= Platform: Win= dows XP

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

=
----f8dVkmeRA4SybqKFY6E5-- From frank.pfohl@yourblindbiz.com Sat Oct 29 09:05:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVqOU-0001OW-LG for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 09:05:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29886 for ; Sat, 29 Oct 2005 09:04:52 -0400 (EDT) Received: from [201.29.197.105] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVqcB-0002lu-9O for dnsext-archive@ietf.org; Sat, 29 Oct 2005 09:19:24 -0400 Message-ID: <000001c5dc88$ca711a00$0100007f@localhost> From: "Larry Wood" To: Subject: Wanna be more man? Check this dude Date: Sat, 29 Oct 2005 13:04:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DC88.CA711A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DC88.CA711A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5DC88.CA711A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

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

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

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

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5DC88.CA711A00-- From owner-namedroppers@ops.ietf.org Sat Oct 29 09:10:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVqTH-0003N0-Rw for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 09:10:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00077 for ; Sat, 29 Oct 2005 09:09:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVqPm-0003Vz-Tt for namedroppers-data@psg.com; Sat, 29 Oct 2005 13:06:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVqPe-0003UU-3P for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 13:06:22 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F0E3633C3F; Sat, 29 Oct 2005 14:06:19 +0100 (BST) Message-ID: <436373CF.9070809@algroup.co.uk> Date: Sat, 29 Oct 2005 14:06:23 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Paul Vixie CC: Thierry Moreau , Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> In-Reply-To: <20051029052602.36B8E11459@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > 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 Sat Oct 29 10:59:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsAv-0002rF-SN for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:59:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05497 for ; Sat, 29 Oct 2005 10:58:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVs6q-0001YV-BB for namedroppers-data@psg.com; Sat, 29 Oct 2005 14:55:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVs6n-0001XQ-LR for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 14:55:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2F61711426; Sat, 29 Oct 2005 14:54:59 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM In-Reply-To: Your message of "Fri, 28 Oct 2005 23:18:23 MST." References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> Date: Sat, 29 Oct 2005 14:54:59 +0000 Message-Id: <20051029145459.2F61711426@sa.vix.com> 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 Sat Oct 29 13:33:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVuaE-0001Q9-0F for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 13:33:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12128 for ; Sat, 29 Oct 2005 13:33:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVuWm-000APa-9L for namedroppers-data@psg.com; Sat, 29 Oct 2005 17:30:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVuWj-000API-4g for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 17:29:57 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 28C6633C1C; Sat, 29 Oct 2005 18:29:55 +0100 (BST) Message-ID: <4363B197.30604@algroup.co.uk> Date: Sat, 29 Oct 2005 18:29:59 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Paul Vixie CC: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> In-Reply-To: <20051029145459.2F61711426@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > 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 mikah1981@wauf.com Sat Oct 29 14:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVvbN-0001zL-Gx for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 14:38:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16879 for ; Sat, 29 Oct 2005 14:38:31 -0400 (EDT) Received: from [201.29.30.155] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVvp7-00037p-Iu for dnsext-archive@ietf.org; Sat, 29 Oct 2005 14:53:07 -0400 Message-ID: <000001c5dcb7$a37e0c80$0100007f@localhost> From: "Collin Wood" To: Subject: OEM Software Date: Sat, 29 Oct 2005 19:38:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DCB7.A37E0C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DCB7.A37E0C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5DCB7.A37E0C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5DCB7.A37E0C80-- From owner-namedroppers@ops.ietf.org Sat Oct 29 17:21:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVy8k-0006cP-SK for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 17:21:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25710 for ; Sat, 29 Oct 2005 17:21:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVy5N-0001Dn-4O for namedroppers-data@psg.com; Sat, 29 Oct 2005 21:17:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [69.31.8.106] (helo=mail.kahlerlarson.org) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVy5M-0001Dc-Eb for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 21:17:56 +0000 Received: by mail.kahlerlarson.org (Postfix, from userid 1000) id B9956971C3; Sat, 29 Oct 2005 17:17:53 -0400 (EDT) Date: Sat, 29 Oct 2005 17:17:53 -0400 From: Matt Larson To: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Message-ID: <20051029211753.GA9275@tornado.kahlerlarson.org> 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 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 Sat Oct 29 18:52:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzYa-0000tu-52 for dnsext-archive@megatron.ietf.org; Sat, 29 Oct 2005 18:52:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29150 for ; Sat, 29 Oct 2005 18:51:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVzVO-0005XQ-Fv for namedroppers-data@psg.com; Sat, 29 Oct 2005 22:48:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVzVN-0005XD-Li for namedroppers@ops.ietf.org; Sat, 29 Oct 2005 22:48:53 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 6C9145A01; Sun, 30 Oct 2005 00:48:51 +0200 (CEST) Date: Sun, 30 Oct 2005 00:48:50 +0200 (CEST) From: Jakob Schlyter cc: DNSSEC deployment , Namedroppers Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM In-Reply-To: Message-ID: 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" 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-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA29150 Until TAKREM is free to implement and use for DNSSEC (without=20 restrictions), I believe it should be ignored. my suggestion is to move forward with a combination of Johan Ihr=E9n's=20 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 Sun Oct 30 14:52:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJEJ-0007MR-Kn for dnsext-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:52:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14482 for ; Sun, 30 Oct 2005 14:52:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWFz6-0007dq-GO for namedroppers-data@psg.com; Sun, 30 Oct 2005 16:24:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWFz5-0007dU-BP for namedroppers@ops.ietf.org; Sun, 30 Oct 2005 16:24:39 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F1A5133C3F; Sun, 30 Oct 2005 16:24:34 +0000 (GMT) Message-ID: <4364F3C3.6050509@algroup.co.uk> Date: Sun, 30 Oct 2005 16:24:35 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Jakob Schlyter CC: DNSSEC deployment , Namedroppers Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> <4363B197.30604@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA14482 Jakob Schlyter wrote: > Until TAKREM is free to implement and use for DNSSEC (without > restrictions), I believe it should be ignored. >=20 > my suggestion is to move forward with a combination of Johan Ihr=E9n's > n-of-m proposal Isn't that also encumbered? > and Mike StJohns' revoke-bit. Dunno the status of this, IP-wise. --=20 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 Sun Oct 30 14:53:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJFH-0008Cy-4d for dnsext-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:53:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14495 for ; Sun, 30 Oct 2005 14:53:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWG4F-0007u8-RH for namedroppers-data@psg.com; Sun, 30 Oct 2005 16:29:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWG4F-0007ts-5V for namedroppers@ops.ietf.org; Sun, 30 Oct 2005 16:29:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j9UGTq7b029281; Sun, 30 Oct 2005 16:29:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j9UGTq7R029278; Sun, 30 Oct 2005 16:29:52 GMT Date: Sun, 30 Oct 2005 16:29:52 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: DNSSEC deployment , Jakob Schlyter , Namedroppers Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Message-ID: <20051030162952.GA20370@vacation.karoshi.com.> 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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA14495 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. > >=20 > > my suggestion is to move forward with a combination of Johan Ihr=E9n'= s > > n-of-m proposal >=20 > Isn't that also encumbered? >=20 > > and Mike StJohns' revoke-bit. >=20 > 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=20 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 >=20 > --=20 > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ >=20 > "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 >=20 > ############################################################# > 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 Mon Oct 31 02:29:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWU6R-0001SI-0n for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 02:29:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17099 for ; Mon, 31 Oct 2005 02:28:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWTyh-0006Dx-AC for namedroppers-data@psg.com; Mon, 31 Oct 2005 07:21:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWTyd-0006Di-IQ for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 07:21:07 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9V7KwEU097176; Mon, 31 Oct 2005 08:20:59 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--35295798" Message-Id: <1989E532-E531-413B-944E-F7E2C1BA01E0@NLnetLabs.nl> Cc: Mark Townsley , Namedroppers , Edward Lewis Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Forwarding report for wcard-clarify Date: Sun, 30 Oct 2005 23:20:42 -0800 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-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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 Mon Oct 31 04:24:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWVtz-0007Fi-NO for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 04:24:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23532 for ; Mon, 31 Oct 2005 04:24:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWVpn-000DDK-6D for namedroppers-data@psg.com; Mon, 31 Oct 2005 09:20:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWVpl-000DCv-2N for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 09:20:05 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9V9Jo67015082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2005 10:19:51 +0100 From: Simon Josefsson To: Anand Kumria Cc: atom@smasher.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt References: <20051031072532.GC29693@progsoc.uts.edu.au> 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 Date: Mon, 31 Oct 2005 10:19:49 +0100 In-Reply-To: <20051031072532.GC29693@progsoc.uts.edu.au> (Anand Kumria's message of "Mon, 31 Oct 2005 18:25:32 +1100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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 Mon Oct 31 07:53:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZAZ-0000ah-Ig for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 07:53:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05182 for ; Mon, 31 Oct 2005 07:53:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWZ6O-000Ncd-Ka for namedroppers-data@psg.com; Mon, 31 Oct 2005 12:49:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWZ6N-000NcL-Mi for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 12:49:27 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F005533C3F; Mon, 31 Oct 2005 12:49:25 +0000 (GMT) Message-ID: <436612D7.10004@algroup.co.uk> Date: Mon, 31 Oct 2005 12:49:27 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Samuel Weiler CC: Namedroppers Subject: Re: NSEC3 design FAQ References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 08:20:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZaF-0002uM-Vn for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 08:20:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07178 for ; Mon, 31 Oct 2005 08:20:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWZXV-000P2r-1x for namedroppers-data@psg.com; Mon, 31 Oct 2005 13:17:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWZXP-000P2N-AB for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 13:17:23 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 14:17:21 +0100 Date: Mon, 31 Oct 2005 14:17:21 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Ben Laurie cc: Samuel Weiler , Namedroppers Subject: Re: NSEC3 design FAQ In-Reply-To: <436612D7.10004@algroup.co.uk> Message-ID: References: <436612D7.10004@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 31 08:59:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaBy-0004dJ-Mo for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 08:59:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09406 for ; Mon, 31 Oct 2005 08:58:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWa7l-0000w8-AQ for namedroppers-data@psg.com; Mon, 31 Oct 2005 13:54:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWa7i-0000vr-27 for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 13:54:56 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1206B33C1C; Mon, 31 Oct 2005 13:54:50 +0000 (GMT) Message-ID: <4366222B.80309@algroup.co.uk> Date: Mon, 31 Oct 2005 13:54:51 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Roy Arends CC: Samuel Weiler , Namedroppers Subject: Re: NSEC3 design FAQ References: <436612D7.10004@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 09:27:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWacw-000200-OB for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:27:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10844 for ; Mon, 31 Oct 2005 09:26:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWaaK-0002YH-3H for namedroppers-data@psg.com; Mon, 31 Oct 2005 14:24:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWaaJ-0002Y2-Ck for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 14:24:27 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 15:24:25 +0100 Date: Mon, 31 Oct 2005 15:24:25 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Ben Laurie cc: Samuel Weiler , Namedroppers Subject: Re: NSEC3 design FAQ In-Reply-To: <4366222B.80309@algroup.co.uk> Message-ID: References: <436612D7.10004@algroup.co.uk> <4366222B.80309@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Mon Oct 31 09:36:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWalW-000479-Ad for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:36:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11327 for ; Mon, 31 Oct 2005 09:35:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWajM-0003B4-1n for namedroppers-data@psg.com; Mon, 31 Oct 2005 14:33:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWajK-0003AQ-Ea for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 14:33:47 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CF19533C1C; Mon, 31 Oct 2005 14:33:41 +0000 (GMT) Message-ID: <43662B47.2070807@algroup.co.uk> Date: Mon, 31 Oct 2005 14:33:43 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Roy Arends CC: Samuel Weiler , Namedroppers Subject: Re: NSEC3 design FAQ References: <436612D7.10004@algroup.co.uk> <4366222B.80309@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 11:29:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcWt-000741-Ea for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:29:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18720 for ; Mon, 31 Oct 2005 11:28:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWcQT-0009tR-QK for namedroppers-data@psg.com; Mon, 31 Oct 2005 16:22:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWcQQ-0009t8-Es for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 16:22:22 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00297B; 31 Oct 2005 11:27:14 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 31 Oct 2005 11:27:04 -0500 Received: from connotech.com (209.71.204.105) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00297A; 31 Oct 2005 11:26:55 -0500 Message-ID: <43664C8E.105@connotech.com> Date: Mon, 31 Oct 2005 11:55:42 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM References: <4362A1E4.40505@connotech.com> In-Reply-To: <4362A1E4.40505@connotech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 12:01:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWd2Y-0006pD-0S for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:01:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20350 for ; Mon, 31 Oct 2005 12:01:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWcxS-000Btv-Tb for namedroppers-data@psg.com; Mon, 31 Oct 2005 16:56:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWcxR-000BtM-Et for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 16:56:29 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2831F33C3F; Mon, 31 Oct 2005 16:56:27 +0000 (GMT) Message-ID: <43664CBC.8080909@algroup.co.uk> Date: Mon, 31 Oct 2005 16:56:28 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Thierry Moreau CC: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> In-Reply-To: <43664C8E.105@connotech.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 12:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdQD-0005hr-JI for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:26:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22129 for ; Mon, 31 Oct 2005 12:25:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdLb-000Deu-V2 for namedroppers-data@psg.com; Mon, 31 Oct 2005 17:21:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWdLZ-000Dea-30 for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 17:21:26 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id j9VHL3DR080427 for ; Mon, 31 Oct 2005 18:21:18 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-31-728822" Message-Id: <7BE15952-A4E7-450F-93F2-1962AA0388E1@NLnetLabs.nl> Content-Transfer-Encoding: 7bit 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 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-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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 Mon Oct 31 12:45:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdiV-0000yH-Rf for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:45:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23288 for ; Mon, 31 Oct 2005 12:44:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdZN-000Eaf-IK for namedroppers-data@psg.com; Mon, 31 Oct 2005 17:35:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdZK-000EaH-In for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 17:35:39 +0000 Received: from kakmonster.int.dactylis.com ([213.114.232.51] [213.114.232.51]) by mxfep01.bredband.com with ESMTP id <20051031173537.IEPX28583.mxfep01.bredband.com@kakmonster.int.dactylis.com> for ; Mon, 31 Oct 2005 18:35:37 +0100 Received: from [192.168.1.240] (kelev.int.dactylis.com [192.168.1.240]) (authenticated bits=0) by kakmonster.int.dactylis.com (8.13.4/8.13.4) with ESMTP id j9VHZaGK006685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 31 Oct 2005 18:35:36 +0100 Message-ID: <436655E8.6030608@better.se> Date: Mon, 31 Oct 2005 18:35:36 +0100 From: Marcus Better User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: NSEC3 chain walking X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060105060507030303000702" 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-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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 Mon Oct 31 13:04:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWe1I-0005CJ-QP for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:04:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24485 for ; Mon, 31 Oct 2005 13:04:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdwG-000G1f-Ph for namedroppers-data@psg.com; Mon, 31 Oct 2005 17:59:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdwF-000G1T-GR for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 17:59:19 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from libra.cus.cam.ac.uk ([131.111.8.19]:60008) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1EWdw8-0008Dt-2r (Exim 4.54) for namedroppers@ops.ietf.org (return-path ); Mon, 31 Oct 2005 17:59:12 +0000 Received: from cet1 by libra.cus.cam.ac.uk with local (Exim 4.54) id 1EWdw8-0005sI-AF; Mon, 31 Oct 2005 17:59:12 +0000 Subject: Re: NSEC3 chain walking To: marcus@better.se (Marcus Better) Date: Mon, 31 Oct 2005 17:59:12 +0000 (GMT) Cc: namedroppers@ops.ietf.org 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] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Oct 31 13:08:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWe4m-00064U-LZ for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:08:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24665 for ; Mon, 31 Oct 2005 13:07:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdzh-000GEB-Rl for namedroppers-data@psg.com; Mon, 31 Oct 2005 18:02:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdzg-000GDy-5x for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 18:02:52 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j9VHwPIC014598 for ; Mon, 31 Oct 2005 12:58:25 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFUaiGC; Mon, 31 Oct 05 12:58:22 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j9VI0ITa024514; Mon, 31 Oct 2005 13:00:19 -0500 (EST) Date: Mon, 31 Oct 2005 13:00:18 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Thierry Moreau cc: Namedroppers , dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM In-Reply-To: <43664C8E.105@connotech.com> Message-ID: References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 sn-web@epitha.com Mon Oct 31 14:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfMD-0002S7-Eb for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 14:30:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01857 for ; Mon, 31 Oct 2005 14:29:54 -0500 (EST) Received: from ns2.tvsom.com.br ([200.242.124.136] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWfaK-0001BS-Nn for dnsext-archive@ietf.org; Mon, 31 Oct 2005 14:44:56 -0500 Message-ID: <000001c5de50$e3c4c280$0100007f@localhost> From: "Caleb Murphy" To: Subject: What IS OEM Software And Why Do You Care? Date: Mon, 31 Oct 2005 19:31:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DE50.E3C4C280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DE50.E3C4C280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5DE50.E3C4C280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5DE50.E3C4C280-- From SamanthaCorrea@fletcherhomes.com Mon Oct 31 15:30:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgI3-0007w9-AR for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:30:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05899 for ; Mon, 31 Oct 2005 15:29:39 -0500 (EST) Received: from [201.137.2.10] (helo=dsl-201-137-2-10.prod-infinitum.com.mx) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWgW7-0007Lp-TS for dnsext-archive@ietf.org; Mon, 31 Oct 2005 15:44:42 -0500 Received: from zkJu@localhost by RYe.int (8.11.6/8.11.6); Mon, 31 Oct 2005 17:05:56 -0400 Message-ID: From: "Ingrid Delacruz" Reply-To: "Ingrid Delacruz" To: dnsext-archive@ietf.org Subject: MS Office XP Pro $49.95 AutoCAD Date: Mon, 31 Oct 2005 14:59:56 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SamanthaCorrea@fletcherhomes.com Content-Type: multipart/mixed; boundary="--gnwmtBQvsRl4jwdeudif" X-Spam-Score: 2.8 (++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Tcb ----gnwmtBQvsRl4jwdeudif Content-Type: text/html; Content-Transfer-Encoding: quoted-printable k
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

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

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

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

Choose:
<= a href=3Dhttp://oemsoftking.com/?J>  =

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



Availa= bility: Available for INSTANT download!
Coupon Code: 3vqhr<= br> Platform: = Windows XP

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

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

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

=

Availabili= ty: Available for INSTANT download!
Coupon Code: ck7Ok
= Platform: Wind= ows XP

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

Microsoft Office 2003 *Professional*<= br> Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=

You Save:



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

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

<= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
List Price:$499.00
Price:$69.99
$429.01 (85%)

Ado= be Acrobat Professional V 7.0
Adobe

Choose= :
 

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



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

= Sales Rank: #4
System requirements  |  Other Versions
Date Co= upon Expires: December 31st, 2005
Ave= rage Customer Review:3D"5 Based on 12559 reviews. Write a review.

= ----gnwmtBQvsRl4jwdeudif-- From RosarioPage@crashposition.com Mon Oct 31 19:06:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWjf7-00008j-TM for dnsext-archive@megatron.ietf.org; Mon, 31 Oct 2005 19:06:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22369 for ; Mon, 31 Oct 2005 19:05:40 -0500 (EST) Received: from jua06-1-82-242-156-250.fbx.proxad.net ([82.242.156.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWjtM-0007lX-08 for dnsext-archive@ietf.org; Mon, 31 Oct 2005 19:20:47 -0500 Received: from GLpA@localhost by vxv.int (8.11.6/8.11.6); Mon, 31 Oct 2005 18:04:54 -0600 Message-ID: From: "Merle Perlmutter" Reply-To: "Merle Perlmutter" To: dnsext-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Office XP Date: Mon, 31 Oct 2005 17:57:54 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: RosarioPage@crashposition.com Content-Type: multipart/mixed; boundary="--Nm1ft3xvIiNDyTJ" X-Spam-Score: 2.6 (++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 4mzQ ----Nm1ft3xvIiNDyTJ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable k
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

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

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

TOP 10 NEW TITLES

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

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

<= /p>

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


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

Sales Rank: #1
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 115878 reviews. Write a review.

=

Adobe Creative Suite 2= *Premium*
A= dobe

Choose:<= tr>
 

List Price:<= /b>$1199.00
Price:$149.99
You Save:$1049.01 (95%)


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

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

Microsoft Office 2003 *Profession= al*
Microsof= t

Choose:
 

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


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

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

Adobe Acrob= at Professional V 7.0
Adobe=

=
Choose:
 

=

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



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

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

----Nm1ft3xvIiNDyTJ--