From owner-namedroppers@ops.ietf.org Mon May 01 02:40:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaS5H-0006fP-Ok for dnsext-archive@lists.ietf.org; Mon, 01 May 2006 02:40:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaS5H-00026o-AV for dnsext-archive@lists.ietf.org; Mon, 01 May 2006 02:40:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FaRzu-0005gY-0B for namedroppers-data@psg.com; Mon, 01 May 2006 06:35:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FaRzr-0005fY-74 for namedroppers@ops.ietf.org; Mon, 01 May 2006 06:35:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k416Z0Wn021359 for ; Mon, 1 May 2006 08:35:01 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k416Z0Cd021358 for namedroppers@ops.ietf.org; Mon, 1 May 2006 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Mon, 1 May 2006 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200605010635.k416Z0Cd021358@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 - 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 d.coll662@grandlisboa.com Fri May 05 15:17:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc5nb-0003Fk-4j for dnsext-archive@ietf.org; Fri, 05 May 2006 15:17:11 -0400 Received: from dv-cms-27b93.adsl.wanadoo.nl ([83.116.25.147] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc5nM-0001aF-HV for dnsext-archive@ietf.org; Fri, 05 May 2006 15:17:11 -0400 Message-ID: <000001c670a2$fee3e980$0100007f@localhost> From: "Dylan Powell" To: Subject: Don't be the "little guy" in the club Date: Fri, 05 May 2006 21:16:57 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C670A2.FEE3E980" 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: 17589c7043b24a47064a4b7516f59671 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C670A2.FEE3E980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C670A2.FEE3E980" ------=_NextPart_001_000E_01C670A2.FEE3E980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C670A2.FEE3E980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby ------=_NextPart_001_000E_01C670A2.FEE3E980-- ------=_NextPart_000_0001_01C670A2.FEE3E980 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@vino> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C670A2.FEE3E980 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@pivo> R0lGODlhQgIDAZEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAgMBAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTlcHAyeb8VbGOXOXQBDCA/R6233TB1gReECoBsSW2AZQp9HY8mgQOTG5 UllxaWLYQbgJ4/mJEQi6Qwr2mEm5CJOK0WryChGbN9J5Y9qCyzBKpBt197eAuqp4EDdXzJic rMDsvBipCN32djxtnNi8nK3NLelt/a2NjXz9XU6+GoEHjADcx/7O124Qv9dOn8BXX1iYr/+v Xz5794K9q/fvIEKD/oLtKehuoAJ4/R7Ks+jQXcWC/xQrEhSYUSHGi/FGScwYRN6mYeKUtWTp 8qW6lthk0qwZU1pOc+ESoIuJoKdQnjN32jSKdJY/jxrvbeTllJ/Uh/qk7ptKtYEhh/M2Uu1o daLYrF/BNt36NOxSrFOvqrW6ieuCrljlkqVbRKUwnUmJpjOHNOjMnsqi+cU59CZNwogPJ/bp OPLRuQHv1r2MGWpWtF8te5079q1ns24/d2Zq+nRVdpsxs+VHOvOuplU9y0ZtRO84yOfA+Z4s rWjhv+omPV7smxnOwI17h4MGtPGzctvIDTp70TZUzWbVotQNsPJ22qrBJ7Q7/qnCuBZb2yYr 0Gvp0uThra+P/f4R8IJ3G//+SVgrjKWz12RAPeMAgEUdJ9g0wg3Y23ISRgdBerW1dRZt3Z3G Wmr4XajaaB6adpWFIdIHW3uiaaZRbCKChtuJH7KHhEi83YgMgUf9xEgDARq4Y3HE/CbJbswF aYyEhi2m44GKzWLifPK5tmGJGJJI3m1asvialTFKCV9aX2Y5JW4Mwbiiay++5csQwSHXSJzT RdiNkAruxU0deg7mDWQOPgiYcnsWSOeECBYmnAPZLeQio2W6lyGkNkYknkidSNSQfVxhytGj 2XnSKD5ksmWjqGEyahI9l3bYFqdtHgLrE682MSsZtT5wa6y67hqaFrmC8atWvA5LbLHGHots ssr/LsvsC216Oaqvwc6GAo3NXostZXatI9prvpIwrQThepttuWWYiGu3p2YxLpqaeNCuufI6 wd55KIXY6raaWrtvmR/BFpKrn63HaWf23tupo1eGx9AfbvU74rwSbxFXR1yiCKbFZGo8ZlQA dQwWZ2uW1fHGkYa5Hccykjtxy+wWDGaMaaaoZnxa4uuvhu3xe/LKXKKss7Urq6idy0aHkfGi 6sbMKn82j4xiZouyxqrOIPdc8b4hUTsz0eYdDXYXGSvaJZWQCusiujmDRjWaUd5MStREzxi0 h/GGjXcOb7+Hc8zvgUo3QuTuvfCFFp7JZtxbhob439HmDTmtMGc6lsiT/64KCuaU4kxlQBvW Ze/QplKaasjaDg1fqZGvzvq6rb8O++t3x0577bbfjnvuuu/Oe+++/w78xEoZGcPwshhv/Ayv JN87wulOMbslfCaYqGLESz8hHdUfb8Ty28cwa/QrzJ6r+DV83kNyjnxfPPvrZ8B8EPGXEH4S 5ItCBfqfVHaOdYVak6dtKKhPDRrSTvZUjWJQZ0h9Ug6i/lQTOTWJL86ZIDX41MDfJLBJD+Rg hSBCOYCVDlUYUdin+BeyyZWwRQGTi0qo1kKKxFBhKwTJCGVjEBSexHmWAiEJWWYHpSWpGhTq C5CQVMShZOM4F2yOEYu4HCVK8ImPkeL0qKhAyf8cSVwqI9nMTEItFlkOboKbyOfwAsYv8swj FbsaGyOWMiy9sWvmu4DTikTEBWoRgVVc0GGQGMU9AsZIDOoPFpEIIUQOso9HDGHgvog1YTlO LGnr2YdqI8ZIrquS7hpbyTpZM6iZzQ9CLNIhT3nKYVSHOE8yICoJiJxGpjIyq/TPnxjDyAMp JWX6gUsvU/fLO3pNk4BTj6ouWZZfWk1dZByZDx+Jsk9p0nVBnJQpc5nLWV4vOjAJpCJvZMgn 2vKbWzTOH5UkSHByS2Y3e5Qo08VJZr4zk+zc5Np65Ul5igx13iJcHe3Ivx7hKJ26JGc4F0kM Jt1JnNZbqDnJyUTrARL/oQaVqCQh6UY1+a2YW5Lb3uiJUcZZ8p7l8Sg+Q/nRtXSPkKsMEACz WUBDZZA6unQoLLlJJJYutIP/SxQFEYVODvLFgRUqlQoTthBgDiSHzlNqqjjHkdLRZ3SbKVh9 rOqp0M0noD1MTVfzdbbgucF9hPrBP98FgrOKda0oIKoqUrIfEaiVrXStq13vite86tUF8yvr +yTQV8CSdXwciBe02MUsoRHrTdQTQWAvwaMTBBag1tSA4iZgizxUtrB4U6wF5uqDyBYBsoMF wWQ/Sz+yYRZE8HpcBkB7LnfZ8Qqb5dGhgFooPzFQqAEETgCXyMDgAgpOrkwMLm+q2o/REISH /1MVwRAGLYiZEboa2uFISBdVGv7LYDzc4Q1LeJCDZRW6wXRkSUhYEoc5EqmwdVYpCzrQVjY0 UH5U6Dl9W1GI0nI4hXxer8zkzK4BjUPulO087cPOzJURk1XCDshMF1KoNpPBGfWZgaEgTMZW 8EgQculf5BuYoRZXi4bEJkEhZM2vVQ5EUdvoiuf2M9bOE5osMynfZlyyLuYTlDe2cIVbbIUM N9GJNHWOHw9VSBPHEpUx1a8i3XpRwymzucfM1L1KhDnyVkqFILWqNGH0M92kVEw+ButJtVPe A1tqa1UQ8pIHlMjsMVmb8IWpBZ3MUAoUE13pIVwYaQbEGwvNxZik8f8n+0nMZe54n80cc4Td RtuA2hTEOQLniIFD50lvEbeZJnFp93yyph2W0JF6mMnkyGKNvridh8YxHTN6ZcY9bNGNPnUZ BsXTlza5TgedjnCJu9sFOvF6txWxb3c5NSs3ZNmzXuo8qFue9ZKO0eadUeiya88ef7Wq25LU ek212dGJO80Q0RS3pUvNsJ2WWO3dKyfcPQLkTqyp8C5Fve+N73zre9/87re//926ddMgzvIr bQrkLVmDRwC427yBwC/w8FWHorUlwDUcFB7aQY4W4xXnuAcELloo2gDkBo+4jFHr3ygLouPh 9CsTTA4Jj8db5toLQSZgXnPTlpzm67TsB1P/vnJRSFpId+ZpfHuKDl3zRuk9lUlyfHrTnyJZ 4xvmdK6HLCjkClCVwSUyfUPOaV/fsqbCrnrYtf50O/2n6xvWyQbPvlqmfhfLzt7Kc58td696 d9qvfS+ulXz0Kb50yHh6O0zgfF914rnDJx67nfNMaYKWuL54lDzgI0pwOh9U825PvFYaVWqJ 71Nt9XSwgAfh9+A0fpwUYlAl/v5r5uy0gJS/fO1X7/X5NlLwbA9xLWVqUNsDKZHGhjzvJ0r0 TXNN290CvapdJ7cf972ysG8p1V0qXI1HXe2AH46RWT/577sEOoe/JYkfaH7WmzP7Le8+8F9J y95y+KeLp3zufR/+/yJebtpaE/Ad6Zll/ZRmMcZF1Jd85ad7rXd9w6VOCIh/cjZs9+cn/aN+ t3cT3UQomUd8RPJ4xydOHXhfpIVnLcd5B0h1UTZobHJyyERoozdhlOUJsJckxqd9gSJRGFhp 7uckR5d/lYZTGWiDDJWDCRV42/MjnZaAPdJ92eRpO9iD52dfwWeCFsVjGIUxtvZOS5NoCzZz vTZA68d0cOdBrcRH8dd7umWBuWVxaMhb8teGUAd2WbdTFFR8ulV0HlZ1U2dBYPhH9Id0l9Y/ cgJ2y4dU2EZ3m9JdeLc5hqgtjWNu7fZWdIVzAEeJ3CNWUFaJmaiJm8iJneiJnwg+PvcFpv/w K9MSLL5QPtfxX2rgWUpAb/gDLKJIiBgGdCcAiak4WxGjA5BYYK4ILkgjixdGL7WIViyAiygX aHoTirrYC7/4Mi40Q9p1GSdEXeK1MNK1Xez1TO81NXXnQ/tgjSRRbSgkQmwTjT+kaCKkXuSY L5X0HdvoXeEFj9AIaWEhjux4bjnzjtbobQwjjUxxMLw4A2hUNqjhZ3YHaw/2c+iBhfnEMd0m fR7DGRApkS94jSvSYBGGFxHhVQuWRj6jYFeyVahGax7DkSF1RiRFkD1GW6zWZ9M0YK/WNqwG ZjBZayIZSmXGTzvpaKfSNjo2Kk2zhWdWaO60Y2wzTJO0Gio5ONP/9JNc05N+E2TkxmVwU0r+ tDNWFn1fdnqu9pDVVWUaKXpnJmZBmZX+h5Q3SZRcOUllSTYziTr1wpTZ5ksn4TXiNpQ7CT02 6WN+xmPccZY+uXwlCU2m5h15SZitRnox9pRoSUlzyVE6CYDCGB9CqZQtApmD2ZRwaTiImZNS 4Jd9uRYgNZeFQ3peaTkOaZCemYWKOZQ8VJp0uSaNU5jPh5JQCZOR2VxN+Un6E0+O2CrS4lze WG1JZW6FqGzS1h3bxjBMo17TlY8XKTprJmrdNpEbY1QtRJfc8Zy8+W3PCSrZSZtUhY12M14s qTnM5p3RSWb4pFWdUzWsI5D7dj8TlwLz/wmKyZifq0ULzkJY+wmgASqgA0qg/3aM/2kHaYWf Bcqg9uafFMcDC9qgASqQhuUDEjqhunJe46gvOnQm3ZiIMhRDWVOedIRVGyqNYmZd4XWOKPqN CZGhvMOQc0RgKjdgBEijUhmT0cZ80aSQpumR7ZmjGAKYMao7USlPBdmepGiROypDvdg3rJmF KelMRWqkuMNLYVlS4Ql6wsSWOvqiqjNetDkaX1qaKaSlU5VsV4qlIxVgl7WcKZeYEoeZaklS nuKUEZlZq8imsIOkO/piLphqswmnoRacbyqlWCmWrYGjfeqn4rk2ldVVIMqlwGmc0zV3xnRu GAOpGnVUaGqpYf/aqI4KORjqBaZKqvqGqlywqqnqqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrOYSANEqrdNKrdVqrdeKrdmqrdvKrd3qrd8KruEq ruNKruVqrueKrumqruvKru3qru86riAAr/NKr/Vqr/eKr/mqr/vKr/3qr/7aAf8qsANLsAVr sAeLsAmrsAWbAdZqNNQ6BhD7BBJbBBS7O9XasNMKNhb7BRy7BB4bBCCbOyL7ABh7NCSrBShr BCrLAyxLOyZLAS6LLTJbBTQbshq7sjj7OzYLADD7sDoLBjz7A0JbA0S7Oj4LAUjbMkb/WwuQ yLSaxQFPGwNSizdK6wBWKzFPK0wnuQtOC7Tr8F5CF7VfC7YrWAJUGzZYywBqK1d7igVai2Cf pyheK62op1KAEC5CC6MsgLYba7Nsq1mjCgVwq1J3p4jYtlybNQE8uynf6VxlhIgI1lR6W5Ha RReveLVke7F/27fc0qGNm0PYNbSai1lxe5KNCzCQe7ntwrhxG7pR8bqve7qKS7nosbqqm7F1 CzyAmwC8+wEfgZDl5jC36wOE65EEc7ewS7yYKwGtu2a4q7zQa4i4QLmwC72x+yud+7Oku7ba +zyIc0LXu5E7ALfPG71ceL7mwbwly71da5IqKr7xa5Ldq7t6/7YUy9sh2bi47Xs7vnsA/vtu goO/4qu4NmC8yiW730G8lLEBrXu8ZiS/2Iu+C1C9TrHAw6kB3ru0nMu/aXW/EbzAQHDAs/vA qXu+wNTAHaxcJzzA6RvC9ButyMhcaPSRF6DBEwPAPXvDgynBLhykxavCctuIx4m8EkmcGRzE d5t3yTm9yYm5FXy8AcO1NpzEsJPDORx0UdzDkSvCVTwFOwzBJwDGJjDG0MrB9bu9MSwGZVzA H1DGJPDG2XLFcVwGdNwDdpwCeOzGXtw6c8zHyqLHOhDIZPzHNDDIyeLHhXwsh3wDjDwCjpy7 auw7Dru/kJyyiuwEliyvmDy1nJy2if+syVYQyp2MxkwwyjHryWl8xgvLyq3syq8My7Esy7Mc rqhMy7eMy7msy7vMy728rbbsy8EszMNMzMVszOoKzMeszMvMzM3szLKczM8szdNMzdVszeka zdeszdvMzd38zNnszeEszuNMzq8MzuWMzgYrALo8AOnszrVcyd0qD9F6B+H6Du4KDMRcz9Ka z+a6z9jazwh7zwEwz/T8z9ca0AXNrtJArWwwrYqwrRAtrQzdyipBrwc9ressrhrNsPG8rf+s 0RjtrSKdriSdywNN0Ots0iPN0QDd0gW7zyFt0DO90vUc0y+9rg4dre080TodADrt09YK1Dz9 00T9yhyN0+3/mtTCfM7WitEKjdIondIurdJIndADbdMhfdUpXdUr7a8gXdVOndX83M9QjdVX DdYBPa8mfdNTjdBhzdVLba5B/dA+PdTZetc7nQiwrNJk7dZcndFeHdf0/Ndb3dZp7dcHPdbz 2tRi3dKKrdVuDdbZms9PDdcEbdAiPdaVHdkHO9lsvdh+/deFTdNwvdiCXdJqPdNTXdOmvdo5 LdE7XdQ9rdd4zdN2XduurNaKzc+E7dtO3duSndGB7dsxPdyiLdOj/a6N7diindmcHdVyLdla zdnVutv3fNgKDdNWrdzITd1t7dyJ3dXQLd34DNmB7dVS3d3pKtG3bdQUja3wTdu6/43ZwU3W Za3e1JrQ9l3fv53c/Q3gSO3f9crcb/3ayk3S6R3Z2W3d+F3aD76wn73UDD7dxK3fYZ3gqn3R j43TqG3Z7UrUQx3b8x3RRp3bFW3d+p3i3/rfj33c9S3g/B3jMc7YHq2t3C3cIE3aB97gGL7g M+7jD17dv73d4v3WQV7hmK3jrH3Zpl3eJX3gHx7er93ZOU3iJ37ls12tuI3lEb7i/E3kAB3c NB7gYy7jL97iBG7jlC3VaG3VN53fEB7XWQ3npY3dTo7a+WrRgG3gaY3fb07dgH3WGv6u6o3Y Fp7ZF/7k4irfFD3iWP7oj66w1+3m9y3Xgy7ogw7olt7VfP8e5+xa4F+96Oea57Rc6rw86gpr 4u8ssB1O6mrevBH+6aRO6Kg+68Gc6gm76qzer5Q+rrUO6mvO68NO7MVu7Kt87Mmu7MsuzqHO 7M8O7dEezM4u7dVu7dfOytSO7dvO7d2er9ru7eFu7S+05+IOruBu7une7bmu7uiu7u8+7vDe re4u7/W+7Oye7vRu7/te7Phu7vrO7wH/zv4u7gAv8AdPzgQf7gaP8Nys8AO767r88N2u7WZt 6Z596gnr5hMv2MD+r23O4SF/434+8UW913od1JK+5SeP8nS9riW/7dS+5AaO8Sft5Kn90TDP rsY92BAe2g2e5OfK5Xmd19da9C7/r9QNX8Us/tKG/uaZXucZ3uQb7/OGTec6v9F4PuGhremA /t0X/9xYz+ZibeRM7tLTnfFGv+pE7962feIqr65iX+0VL+XhvdmdXdlHjuBN/txAT+dB3+vJ DdqXvdrnXdxIftpyf+RN3+E/fvY8n/Yrz/Js3+UN3fayreX4rPSlzL5Mz+EXTtxXD95nj/Y/ n+icXuHlzq+avfWFf9aIbuQWfevm/fmwf+tOj66xDd/yLdSSjvRQvvkB4O6TDftKzuPrbeGJ 392vb/bN3+pJDdpVH+WN7/zorfhjb/fQ/+R1P64hvvbf360u//voev3QLvPOzf2eDuQjj/h8 b/YMPuQA/67nTX/8ia78Ob7+XA/48FrlBBAp8pIVeTXzjJMXy8HGbv0CP08jTTJLVWht3ReO 5ZmGgRvPdSA+fMeHCEYmlCCQeFkQh8Jf0dKcTIuU2rVqTEqW2iMUCYR+h9jeM+t8oi2QLbvW kXPmdNFodE/IUWaM1S9QcJAwZucQp1BRCXCRyhGyYSuScqWxcrAPM/Jy0/NTEBER1Kxs8Yt0 0DR1s5NVRvM10FW21lb00FZ3l7fX9/eX1g3VcVKhRvg0OQN3B/gZOlp6mprrxahyeVr7olmn GjxcfJzcT1vI7ZENjjHCaTjd/V0syqorZW0+qsY7p/wfYECB1M4lMciiwrEM2P+o2JP0ACJE SQ8VRsSH0F1FbhL6JRr4EWRIkZTOJVQ4TB67hwxNtmTI0iVGhAvXyDwpo+ONkTt59vRp6ZoS a0NhSLzpsOLMmElvEjWaEKahnD+pVrU6sCTRpi0vMl168ilSsGMX2oSqVGrHq2vZtoW2bB0q uSrDjOmSjwmaMj/w0mpyF8lGBjl5uDV8GPEnwb0aLRZai3BiyZMpzyoX1zEYyFMrd/b8uSxo WZFFlzadOPNpM6RVt36V2lasf7Bdz2B9jdjKxsaw0A1pkPcZS8FlEQNuj7jmVVf4oNBDJ4/s 6NGl96jt6XYLJiqMJafhPaBefciSgQeVsUo8i8HvPTL/c8cDnxDw41cXQZ8QbU4E9XPkjLsd 5Cjqrr30Aqunrin48m0XfQpcSZ2+vEhpQpT60+6SvBoaj4t5cqPhOehKOGEP++qzozrrrvuj kOyG67CNCDXrkMMCI5rkngVjBMZBDuF5w6J0NFJwvSBJguM49fDxcEcQ5cPjgwDwk9LEEjmw 0pwr8olRvAhTotGLJdGBh8g28gLkwsH+c+GuLbk0EsYNdaRRNw/VYLAWIx+kSE55+BzwzjbP A07JBP9Asr8nsdxjUSrrSKG5+Sz7ziaWtJjoKEzP2oqFMV8y6iWl0kzARe6KfFNI3vxcdTc/ y3xVGilgjbM9V5ssk0DzBCEU/8E/l4yTOREbbU6TEDMI0dgZMlvluO001Uq5Dzs1iQyzKkTL j1J/fVXDejrRkVWM3gl3Tq54vFTVHIPMyFl1O4UTEjg15PXWdmkjUVgo9W1UWHxLQebQZ9H6 NjS4KgiLrFAzJURbMa+VFTBGvFzwSyKPqBVPXeZyxUZTxPuS4ht1LeVjvMgUkp6TmVOUWBTr Q9a5R0tMVlmAh4qqKZjEeoq7gxOuFGFsV1szz1G3/Wnk2f5JUZzULtZTwpM9xuxbiP8CA+OQ 02x40IzJS/oyaX9beuwVK+Ha7LTVfsbotRtA2+245U6lbbnhnhvvvOPVOxSi+f4b8PwCx+Lu wQ0/PP80xNPqR/HGHe/q8RYKj5xyvOsu6ruCMOxl8so9X/tykjDXjnO/Pz/dcla6bFZTW5dQ +XVeOkeddtVCZ5PPoBfeFD3eb7fN9NqFX/F3oGbi+VmFoaqW01dmH76z4iFhOhzpIae2+Z1/ dqp0tYoiA08crcdtfBmi7k0Yr0nZ2EKVD51Qv0jzdTRmmlGkblLVWydr4d6Rx152wftVt44W DbBhgl4k25wv0IMxGLHHToKAz8xihqX7VIlK8/sX3Z6mhpQxy059ad8uZtcx3RzIQFkQw19y NbERZg1dglIEkNLVIwrBL0EbO6Cy0BTCGA5QZH5Ilh4uaEEM0sd+KoJeCXv/FDD37MiBOXri CnuoDkMhaE47NJW9aFIjeX2KWxHMBjsaeCqaNORWsFDUsE6UQTceq41S4pfNlijALgrohbsB FBbRQSAzPa0dddpQGmboxTP26YsSa5MMPREXiV0RTMDCwhqfIz/6pciSGqQU9ALAxEcOcoqE IlcfM2TGPRkoXLMq5BPT1StbhXJcpdRi5lDmqyl+Mo0x8NcbSyApF8Asf8PzJLBc5T8BjfJg sgyjFXF1qnK1rVa5BNe6JMJFG4FSdNgcUi3FJ6735MtYwNxXvzRZM052Toc3vFFgPCih15HR hiGjxyJjCcldJemMZzJZXSiGSrEVUp9hShkUaShE/5bJj5IyY2MlFaolTnbSjrOR3iyPVJXy FYJ64Lhoa563jX+SjKKc+ChWyAaSjaqmow9VqVtOepqUrhSmVmmpaV4aU5v2ZKalqelNeapR Fi5HeDvt6VCJWg2hFhWpSe0e45TaVKeOgzCFeepUqfqLqEq1qlnVKiuuitWtfhWsjuiqV8Na VrMSbqxkPeta2cqMtHqkrXGVK0Tf6o+53jWsddXrXvnaV7/+FbCBFexgCVtYwx4WsYlV7GIZ 21jHPhaykZXsZClbWcteFrOZ1exmOdtZz34WtKEV7WhJW1rTnha1qVXtalnbWte+Fraxle1s aVtb294Wt7nV7W5521vf/jQWuMEV7nCJW1zjHhe5yVXucpnbXOc+F7rRle50qVtd614Xu9nV 7na5213vfhe84RWvcgsAADs= ------=_NextPart_000_0001_01C670A2.FEE3E980-- From owner-namedroppers@ops.ietf.org Sat May 06 18:50:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcVbS-0007Oa-9t for dnsext-archive@lists.ietf.org; Sat, 06 May 2006 18:50:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcVbM-0007QD-NB for dnsext-archive@lists.ietf.org; Sat, 06 May 2006 18:50:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FcVVW-000FyD-VM for namedroppers-data@psg.com; Sat, 06 May 2006 22:44:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FcVVU-000Fxs-I0 for namedroppers@ops.ietf.org; Sat, 06 May 2006 22:44:12 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B568940EE; Sun, 7 May 2006 00:44:01 +0200 (CEST) Date: Sun, 7 May 2006 00:44:01 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? Message-ID: <20060506224401.GA3079@outpost.ds9a.nl> References: <20060411113809.GD19636@outpost.ds9a.nl> <51467.1144767928@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51467.1144767928@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Tue, Apr 11, 2006 at 03:05:28PM +0000, Paul Vixie wrote: > (to be able to resolve their own names when their transit pipe is down.) as > attractive as it is to do a "pure" nameserver with nearly zero config, it's > unrealistic in today's polluted local namespaces. Fixed in 3.1-pre1, http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-1 , 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 May 08 11:47:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7xe-0002MA-KL for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 11:47:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7xd-00084S-8X for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 11:47:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd7s1-000ARv-38 for namedroppers-data@psg.com; Mon, 08 May 2006 15:42:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd7s0-000ARE-6O for namedroppers@ops.ietf.org; Mon, 08 May 2006 15:42:00 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k48FfoAc083960 for ; Mon, 8 May 2006 11:41:51 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060508094001.03182b80@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 May 2006 11:41:23 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Standardize RSA/SHA256 ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Dear colleagues The Working group has had a document for the last few months that defines a new DNSKEY algorithm RSA/SHA256. Discussion on this document has been non existent. The chairs would like to ask the working group following question: Is there support in the working group to add a new RSA algorithm to the list of supported algorithms? The benefit is SHA256 is stronger digest than the SHA1 that is in use today. Given that DNSSEC signatures are over structured data, it is not known how much effort is needed to create RRSET that matches existing signature for a particular name, type and class. Further consideration is the fact that DNSSEC signatures have a limited lifetime, restricting the window that a forged RRSET can be used by DNSSEC validating resolvers. The alternative to defining RSA/SHA256 now is to wait for efforts to standardize new digest algorithms by NIST which will take 4-5 years. Please give your chairs guidance on how to proceed, if there is sufficient support (minimum of 5 people) for defining RSA/SHA256 we will start a formal last call. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 08 13:25:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9U3-0005dC-Mh for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:25:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9U1-0004tq-8q for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:25:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9Qt-000L61-VH for namedroppers-data@psg.com; Mon, 08 May 2006 17:22:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9Qs-000L5S-HC for namedroppers@ops.ietf.org; Mon, 08 May 2006 17:22:07 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k48HLvd1084466 for ; Mon, 8 May 2006 13:21:57 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k48HLvnr084465 for namedroppers@ops.ietf.org; Mon, 8 May 2006 13:21:57 -0400 (EDT) (envelope-from namedroppers) Received: from [158.69.80.164] (helo=hobbes.columbia.sparta.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd8Wn-000Evp-2U for namedroppers@ops.ietf.org; Mon, 08 May 2006 16:24:09 +0000 Received: from [157.185.80.164] (localhost [127.0.0.1]) by hobbes.columbia.sparta.com (Postfix) with ESMTP id E979E446E07; Mon, 8 May 2006 12:24:06 -0400 (EDT) Date: Mon, 8 May 2006 12:24:05 -0400 From: Russ Mundy Subject: Re: Standardize RSA/SHA256 ? To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org X-Priority: 3 In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I strongly support the need for standarization of this algorithm and incorporation of it into the set of DNS RFCs. Russ Mundy On 5/8/06 at 11:41 AM -0400, =C3=93lafur Gu=E2=80=BAmundsson /DNSEXT co-ch= air wrote:=20 > > >Dear colleagues > >The Working group has had a document for the last few months that >defines a new DNSKEY algorithm RSA/SHA256. Discussion on this >document has been non existent. > >The chairs would like to ask the working group following question: >Is there support in the working group to add a new RSA algorithm >to the list of supported algorithms? > >The benefit is SHA256 is stronger digest than the SHA1 that is in use >today. Given that DNSSEC signatures are over structured data, it is >not known how much effort is needed to create RRSET that matches >existing signature for a particular name, type and class. >Further consideration is the fact that DNSSEC signatures >have a limited lifetime, restricting the window that a forged RRSET >can be used by DNSSEC validating resolvers. > >The alternative to defining RSA/SHA256 now is to wait for efforts to >standardize new digest algorithms by NIST which will take 4-5 years. > >Please give your chairs guidance on how to proceed, if there is >sufficient support (minimum of 5 people) for defining RSA/SHA256 >we will start a formal last call. > > Olafur & Olaf=20 > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 May 08 13:47:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9pQ-0005iy-F4 for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:47:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9pP-0006Ue-2e for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:47:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9nC-000NfP-Ie for namedroppers-data@psg.com; Mon, 08 May 2006 17:45:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9nB-000NfA-0o for namedroppers@ops.ietf.org; Mon, 08 May 2006 17:45:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k48Hj2te013161; Mon, 8 May 2006 19:45:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k48Hiwbs013148; Mon, 8 May 2006 19:44:58 +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 k48HivBZ064844; Mon, 8 May 2006 19:44:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200605081744.k48HivBZ064844@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? In-reply-to: Your message of Mon, 08 May 2006 11:41:23 EDT. <6.2.5.6.2.20060508094001.03182b80@ogud.com> Date: Mon, 08 May 2006 19:44:57 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 In your previous mail you wrote: Please give your chairs guidance on how to proceed, if there is sufficient support (minimum of 5 people) for defining RSA/SHA256 we will start a formal last call. => I support Francis.Dupont@point6.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 08 13:54:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9vw-0008S8-P6 for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:54:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9vv-00070I-BU for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 13:54:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9uT-000Oa2-5Y for namedroppers-data@psg.com; Mon, 08 May 2006 17:52:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fd9uS-000OZe-Dk for namedroppers@ops.ietf.org; Mon, 08 May 2006 17:52:40 +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 B0F22278 for ; Mon, 8 May 2006 13:52:36 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 571045C1D for ; Mon, 8 May 2006 13:52:34 -0400 (EDT) Date: Mon, 08 May 2006 13:52:34 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> References: <6.2.5.6.2.20060508094001.03182b80@ogud.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20060508175234.571045C1D@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c At Mon, 08 May 2006 11:41:23 -0400, =D3lafur Gu=F0mundsson wrote: >=20 > Please give your chairs guidance on how to proceed, if there is > sufficient support (minimum of 5 people) for defining RSA/SHA256 > we will start a formal last call. I support standardizing RSA/SHA256 (As the chairs no doubt remember, I threatened to write a draft proposing this, but somebody else kindly wrote it first....) -- to unsubscribe send a message to namedroppers-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 May 08 14:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdALK-0007bg-9J for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 14:20:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdALJ-00082U-Pg for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 14:20:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdAJH-0001Mj-G0 for namedroppers-data@psg.com; Mon, 08 May 2006 18:18:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdAJG-0001MN-Ib for namedroppers@ops.ietf.org; Mon, 08 May 2006 18:18:18 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 84FE256821; Mon, 8 May 2006 11:18:16 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060508135706.03c44140@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 08 May 2006 14:18:16 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Um... OK... I don't think this is the right question=20 or set of questions to ask. Obviously stronger is good but: 1) Should we standardize RSA/SHA256? - Yes 2) Should we standardize DSA/SHA256? - No comment? 3) Should we deprecate RSA/SHA1? Yes, but what does that mean? 4) Should RSA/SHA256 be Mandatory to Implement=20 (at both the signing side and the resolver side)? Yes. 5) Should the root (and/or lower trust anchors)=20 be signed with RSA/SHA256 in addition to or in=20 replacement of RSA/SHA1? - Well, that brings in=20 the whole question of algorithm rollover...and "downgrade attacks" *sigh* So while I would agree that this might be "A GOOD=20 THING" - I think its handwaving to just say yes=20 to RSA/SHA256 without dealing with all the other things. DNSSEC has gotten consistently more complex - the=20 addition of NSEC3 and the interactions with NSEC=20 still don't give me warm fuzzies. After many=20 long sessions with the folks that should know how=20 this should all work I still don't have a good=20 feeling about using more than one signature=20 algorithm in a trust chain. How do=20 NSEC/NSEC3/RSASHA1/RSASHA256 all play together? The specific document has some issues as well -=20 specifically dealing with RSA DNSKEY records - it=20 shouldn't have a TBA for the format of RSA in=20 DNSKEY records for example. While it's OK to=20 cite PKCS2.1 as the source for the format of the=20 RSA/SHA256 signature blob (specifically the=20 prefix), it should also give the actual ASN.1=20 used to form the blob and consider that the=20 definitive version. As above, I'd like a bit=20 more discussion on operational considerations for=20 switching from SHA1 to SHA256. Later, Mike At 11:41 AM 5/8/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Dear colleagues > >The Working group has had a document for the last few months that >defines a new DNSKEY algorithm RSA/SHA256. Discussion on this >document has been non existent. > >The chairs would like to ask the working group following question: >Is there support in the working group to add a new RSA algorithm >to the list of supported algorithms? > >The benefit is SHA256 is stronger digest than the SHA1 that is in use >today. Given that DNSSEC signatures are over structured data, it is >not known how much effort is needed to create RRSET that matches >existing signature for a particular name, type and class. >Further consideration is the fact that DNSSEC signatures >have a limited lifetime, restricting the window that a forged RRSET >can be used by DNSSEC validating resolvers. > >The alternative to defining RSA/SHA256 now is to wait for efforts to >standardize new digest algorithms by NIST which will take 4-5 years. > >Please give your chairs guidance on how to proceed, if there is >sufficient support (minimum of 5 people) for defining RSA/SHA256 >we will start a formal last call. > > 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: -- to unsubscribe send a message to namedroppers-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 May 08 15:53:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBnn-0000Ym-LK for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 15:53:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBnn-0004Tx-8z for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 15:53:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdBkE-000Cgw-9k for namedroppers-data@psg.com; Mon, 08 May 2006 19:50:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdBk5-000Cd6-Ec for namedroppers@ops.ietf.org; Mon, 08 May 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k48Jo2et001106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FdBk2-0008GB-Er; Mon, 08 May 2006 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-rollover-requirements-01.txt Message-Id: Date: Mon, 08 May 2006 15:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 Trust Anchor Rollover Author(s) : S. Crocker, et al. Filename : draft-ietf-dnsext-rollover-requirements-01.txt Pages : 11 Date : 2006-5-8 Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-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-rollover-requirements-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-rollover-requirements-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: <2006-5-8144030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rollover-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-8144030.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 08 16:28:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCL5-0006lV-3C for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 16:28:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCL2-0006TM-Cm for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 16:28:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCIJ-000HHA-RC for namedroppers-data@psg.com; Mon, 08 May 2006 20:25:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCII-000HGw-Uy for namedroppers@ops.ietf.org; Mon, 08 May 2006 20:25:27 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 9817A11D99B; Mon, 8 May 2006 13:25:24 -0700 (PDT) From: Wes Hardaker To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? Organization: Sparta References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> Date: Mon, 08 May 2006 13:25:24 -0700 In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> (ogud@ogud.com's message of "Mon, 08 May 2006 11:41:23 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Mon, 08 May 2006 11:41:23 -0400, ogud@ogud.com (Olafur Gudmundsson) said: Olafur> The alternative to defining RSA/SHA256 now is to wait for efforts to Olafur> standardize new digest algorithms by NIST which will take 4-5 years. I believe we should standardize it now rather than wait. If we believe that a particular algorithm will likely used in the future, and I believe this one will be, then I don't see the point in waiting to define it later if we have the time and energy now. More importantly, I think it would be detrimental to delay defining it now assuming it will be defined at some point. The only way I think not defining it now is wise is if we're uncertain that it'll be selected for future use. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 08 16:54:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCkp-0001oe-7i for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 16:54:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCko-0008WG-OI for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 16:54:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCiK-000KUV-19 for namedroppers-data@psg.com; Mon, 08 May 2006 20:52:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCiI-000KUI-Qa for namedroppers@ops.ietf.org; Mon, 08 May 2006 20:52:19 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k48Kq3L1085579; Mon, 8 May 2006 16:52:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060508163855.03491f88@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 May 2006 16:51:30 -0400 To: Mike StJohns , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <7.0.1.0.2.20060508135706.03c44140@nominum.com> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <7.0.1.0.2.20060508135706.03c44140@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e At 14:18 08/05/2006, Mike StJohns wrote: >Um... > >OK... I don't think this is the right question=20 >or set of questions to ask. Obviously stronger is good but: > >1) Should we standardize RSA/SHA256? - Yes >2) Should we standardize DSA/SHA256? - No comment? >3) Should we deprecate RSA/SHA1? Yes, but what does that mean? >4) Should RSA/SHA256 be Mandatory to Implement=20 >(at both the signing side and the resolver side)? Yes. >5) Should the root (and/or lower trust anchors)=20 >be signed with RSA/SHA256 in addition to or in=20 >replacement of RSA/SHA1? - Well, that brings in=20 >the whole question of algorithm rollover...and "downgrade attacks" *sigh* > >So while I would agree that this might be "A=20 >GOOD THING" - I think its handwaving to just say=20 >yes to RSA/SHA256 without dealing with all the other things. Thanks Mike for your list of follow up questions, few comments: Q2: is a different question and does not belong here, but this is a related question. As far as I can tell right now no-one has shown any= interest in using DSA when deploying DNSSEC. As long as that is the case the question about DSA/SHA256 should be asked at the same time as the kill DSA question is raised. Q3: My personal opinion not speaking as a chair: If RSA/SHA256 is specified then RSA/SHA1 should be tagged as "Not recommended". Q4: If we are defining it and we think it is "better" than what is used today then it should be mandatory to implement. Q5: Outside the scope of namedroppers/DNSEXT, we=20 provide the toys, the operators get to pick which one they play with. >DNSSEC has gotten consistently more complex -=20 >the addition of NSEC3 and the interactions with=20 >NSEC still don't give me warm fuzzies. After=20 >many long sessions with the folks that should=20 >know how this should all work I still don't have=20 >a good feeling about using more than one=20 >signature algorithm in a trust chain. How do=20 >NSEC/NSEC3/RSASHA1/RSASHA256 all play together? Excellent point, this is one of the reasons why=20 Olaf and I are looking for guidance. Holding off changing signature algorithms right now may reduce the cost of deployment, so we need to weight the tradeoffs. Thanks for your feedback. Olafur >At 11:41 AM 5/8/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: > > >>Dear colleagues >> >>The Working group has had a document for the last few months that >>defines a new DNSKEY algorithm RSA/SHA256. Discussion on this >>document has been non existent. >> >>The chairs would like to ask the working group following question: >>Is there support in the working group to add a new RSA algorithm >>to the list of supported algorithms? >> >>The benefit is SHA256 is stronger digest than the SHA1 that is in use >>today. Given that DNSSEC signatures are over structured data, it is >>not known how much effort is needed to create RRSET that matches >>existing signature for a particular name, type and class. >>Further consideration is the fact that DNSSEC signatures >>have a limited lifetime, restricting the window that a forged RRSET >>can be used by DNSSEC validating resolvers. >> >>The alternative to defining RSA/SHA256 now is to wait for efforts to >>standardize new digest algorithms by NIST which will take 4-5 years. >> >>Please give your chairs guidance on how to proceed, if there is >>sufficient support (minimum of 5 people) for defining RSA/SHA256 >>we will start a formal last call. >> >> 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: > > -- to unsubscribe send a message to namedroppers-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 May 08 17:06:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCvp-0004fz-K1 for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 17:06:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCvp-0000Qa-5O for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 17:06:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCu7-000LjT-TH for namedroppers-data@psg.com; Mon, 08 May 2006 21:04:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdCu6-000LjH-UI for namedroppers@ops.ietf.org; Mon, 08 May 2006 21:04:31 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k48L4ONR025849; Mon, 8 May 2006 14:04:24 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:04:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Standardize RSA/SHA256 ? Date: Mon, 8 May 2006 14:04:19 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01C672A8.4C80F5F0" Message-ID: <198A730C2044DE4A96749D13E167AD37ABA21D@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Standardize RSA/SHA256 ? Thread-Index: AcZy4cUi3eBt6CYtRgOQRY0TnkT0LAAACBZg From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= , "Mike StJohns" , X-OriginalArrivalTime: 08 May 2006 21:04:19.0373 (UTC) FILETIME=[F91535D0:01C672E2] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C672A8.4C80F5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of =D3lafur=20 > Gu=F0mundsson /DNSEXT co-chair > At 14:18 08/05/2006, Mike StJohns wrote: > >Um... > > > >OK... I don't think this is the right question or set of=20 > questions to=20 > >ask. Obviously stronger is good but: > > > >1) Should we standardize RSA/SHA256? - Yes > >2) Should we standardize DSA/SHA256? - No comment? > >3) Should we deprecate RSA/SHA1? Yes, but what does that mean? > >4) Should RSA/SHA256 be Mandatory to Implement (at both the signing=20 > >side and the resolver side)? Yes. > >5) Should the root (and/or lower trust anchors) be signed with=20 > >RSA/SHA256 in addition to or in replacement of RSA/SHA1? -=20 > Well, that=20 > >brings in the whole question of algorithm rollover...and "downgrade=20 > >attacks" *sigh* > > > >So while I would agree that this might be "A GOOD THING" - I=20 > think its=20 > >handwaving to just say yes to RSA/SHA256 without dealing=20 > with all the=20 > >other things. >=20 > Thanks Mike for your list of follow up questions, few comments: > Q2: is a different question and does not belong here, but=20 > this is a related > question. As far as I can tell right now no-one has=20 > shown any interest > in using DSA when deploying DNSSEC. As long as that=20 > is the case the > question about DSA/SHA256 should be asked at the=20 > same time as the > kill DSA question is raised. DSA signatures are as secure as the RSA 2048 signatures but the = signature itself is only 64 bytes as opposed to 256 bytes Unlike ECC DSA is unencumbered. I think that it is by far the most interesting technology on offer. It is true that the cryptographers are worried about SHA1 but a lot more cryptographers are worried about RSA1024 than the type of attack against SHA1 that is relevant to DNSSEC. ------=_NextPart_000_0007_01C672A8.4C80F5F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MDgyMTA0MTlaMCMGCSqGSIb3DQEJBDEWBBSY 8Y0IqRu3nDw5swc0ryFjjQGkSzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYDIgQdYAq7JjpD1+5z++YKIsqnX PcL0hjzkrOkUw5LFv4U1pw2pXcojk1aEXoDuvbTHcCwZAMzbBevm6/2faG/yZrMRUXuj4z7nuC1r fLJP7c0meauCGgS5NslbsHgze3ueokO1ddCEXXO19bXiQ9wk+AaypdSOAfzmNUN2ZZ8+CAAAAAAA AA== ------=_NextPart_000_0007_01C672A8.4C80F5F0-- -- to unsubscribe send a message to namedroppers-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 May 08 17:13:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdD37-0004s9-31 for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 17:13:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdD35-0000kK-LL for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 17:13:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdD1O-000MW9-9A for namedroppers-data@psg.com; Mon, 08 May 2006 21:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdD1N-000MVu-Ja for namedroppers@ops.ietf.org; Mon, 08 May 2006 21:12:01 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k48LBunX026305; Mon, 8 May 2006 14:11:56 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:11:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Standardize RSA/SHA256 ? Date: Mon, 8 May 2006 14:11:50 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01C672A9.59D57A40" Message-ID: <198A730C2044DE4A96749D13E167AD37ABA222@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Standardize RSA/SHA256 ? Thread-Index: AcZy3hkl6yCVpIAFT1qUxGELhwQzIQABXmEA From: "Hallam-Baker, Phillip" To: "Wes Hardaker" , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= Cc: X-OriginalArrivalTime: 08 May 2006 21:11:51.0650 (UTC) FILETIME=[06A93420:01C672E4] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C672A9.59D57A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Wes Hardaker > >>>>> On Mon, 08 May 2006 11:41:23 -0400, ogud@ogud.com > (Olafur Gudmundsson) said: > > Olafur> The alternative to defining RSA/SHA256 now is to wait for > Olafur> efforts to standardize new digest algorithms by NIST > which will take 4-5 years. > > I believe we should standardize it now rather than wait. If > we believe that a particular algorithm will likely used in > the future, and I believe this one will be, then I don't see > the point in waiting to define it later if we have the time > and energy now. More importantly, I think it would be > detrimental to delay defining it now assuming it will be > defined at some point. I second this, it is far more important to get something that looks like DNSSEC deployed than that it be secure against every imaginable attack. History shows that we are considerably better at doing in the field fixes to broken crypto than deploying crypto infrastructure. Consider that SSL2.0 and WEP were both proposed after DNSSEC but deployed in strong, fixed form some time ago. Waiting for the outcome of the NIST competition is missing the point, whatever comes out of that process will be functionaly identical to SHA256. ------=_NextPart_000_0010_01C672A9.59D57A40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MDgyMTExNTBaMCMGCSqGSIb3DQEJBDEWBBT6 VCvk3eIi8wKUlPWx/QOjHFSE+jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYACgOy4TefvccYIz5HP0nEZ+mjX D/EFi6ZxdcevWikyXXvkBP7frzDIk4sUTKpQ6hzrZANpKA3Lj9QJ3MqyjPhlncQ2tfqMEy9+6t03 n6vbRQEtTLNGge61dw93sPr1+BJvWaK9aCq9mE2X54OEx1GNf18Y23eCQ7WDgH6Pfn1ivQAAAAAA AA== ------=_NextPart_000_0010_01C672A9.59D57A40-- -- to unsubscribe send a message to namedroppers-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 May 08 18:02:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDoG-0003aw-4n for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 18:02:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdDoB-0004Id-Lw for dnsext-archive@lists.ietf.org; Mon, 08 May 2006 18:02:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdDlW-0001O1-Lh for namedroppers-data@psg.com; Mon, 08 May 2006 21:59:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdDlV-0001Nn-R5 for namedroppers@ops.ietf.org; Mon, 08 May 2006 21:59:42 +0000 Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k48LxTfx016335; Mon, 8 May 2006 15:59:29 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k48LvjSg022995; Mon, 8 May 2006 15:57:45 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k48Lvj0E022991; Mon, 8 May 2006 15:57:45 -0600 Date: Mon, 8 May 2006 15:57:45 -0600 Message-Id: <200605082157.k48Lvj0E022991@localhost.localdomain> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: ogud@ogud.com Cc: namedroppers@ops.ietf.org In-reply-to: Yourmessage <6.2.5.6.2.20060508163855.03491f88@ogud.com> Subject: Re: Standardize RSA/SHA256 ? X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Without a risk analysis specific to DNSSEC, I cannot support standardization of RSA/SHA256. Hilarie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From micymv6@ufdgfdfsdf.gnway.net Mon May 08 23:48:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdJCp-0007wm-2N for DNSEXT-ARCHIVE@LISTS.IETF.ORG; Mon, 08 May 2006 23:48:15 -0400 Received: from [221.209.142.130] (helo=ufdgfdfsdf.gnway.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdJCl-0005wq-Un for DNSEXT-ARCHIVE@LISTS.IETF.ORG; Mon, 08 May 2006 23:48:15 -0400 Received: from qdbhl2 (unknown [154.98.158.126]) by ufdgfdfsdf.gnway.net (Coremail) with SMTP id U96iR19M5EKG7Sma.1 for ; Tue, 09 May 2006 11:49:31 +0800 (CST) X-Originating-IP: [154.98.158.126] Date: Tue, 09 May 2006 11:49:31 +0800 From: =?shift-jis?B?lJCW2A==?= To: Subject: =?shift-jis?B?l+GCzIyPgUGU6ZangsWCtw==?= Mime-Version: 1.0 Content-Type: text/plain; charset="shift-jis" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express X-MimeOLE: Produced By Microsoft MimeOLE Message-ID: <2006050952037.44528@ufdgfdfsdf.gnway.net> X-Spam-Score: 4.9 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 gseCpILggsWCt4FCDQoNCpPgj4+CyILMgsWCt4KqgUGX4YLMlYKLQ5GKjuiSVIK1gsUNCoNSg36D hYNqg2WDQoLwjmeCooLNgraC34LcgrWCvYFCDQoNCo1sgqaCxIKigr2C5oLogUGPl5CrgsyV+4LM l5iXcJemgqqNgoKiguaCpILFgreBQg0KkeWO6ILFgs2CyIKigsyCxYujkYiXpoLgkuGCrYLEgUEx MJLKgtmCx4LFDQqSvJDag0GDaIOMg1iM8Iq3grWCxIFBjaGCzYxnkdGU1I2GgtyCxY7ogsmT/ILq gtyCtYK9gUINCoK7gsyDUoLMl0aSQoLwj9CJ7oK1gsSC4ILngqSCsYLGgsmCyILBgr2CzILFgUEN Co2hk3iCx4KkgsWCt4KpgUINCg0KgUBodHRwOi8vd3d3LmxvdmUtZGVhbHMuY29tL2hvdA== From owner-namedroppers@ops.ietf.org Tue May 09 08:00:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQrf-0003rW-F0 for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 07:58:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdQk3-0004Wq-Jh for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 07:51:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdQfl-000IZ8-3P for namedroppers-data@psg.com; Tue, 09 May 2006 11:46:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdQfj-000IYb-Ha for namedroppers@ops.ietf.org; Tue, 09 May 2006 11:46:36 +0000 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k49BkBmj011427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 May 2006 13:46:12 +0200 From: Simon Josefsson To: "Hilarie Orman" Cc: ogud@ogud.com, namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508163855.03491f88@ogud.com> <200605082157.k48Lvj0E022991@localhost.localdomain> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060509:ogud@ogud.com::6c32gSqi9T/v82Sr:BGwp X-Hashcash: 1:22:060509:ho@alum.mit.edu::Gllr9RCkskkELRrF:VNEk X-Hashcash: 1:22:060509:namedroppers@ops.ietf.org::aL/jPENTIu5PsBFY:KZPc Date: Tue, 09 May 2006 13:46:11 +0200 In-Reply-To: <200605082157.k48Lvj0E022991@localhost.localdomain> (Hilarie Orman's message of "Mon, 8 May 2006 15:57:45 -0600") Message-ID: <87d5enfmkc.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 "Hilarie Orman" writes: > Without a risk analysis specific to DNSSEC, I cannot support standardization > of RSA/SHA256. I'm inclined to agree. What problem would we be solving by moving from RSA-SHA1 to RSA-SHA256? SHA-2, and RSA-SHA256, has seen less scrutiny by experts than RSA-SHA1. Perhaps we can specify RSA-SHA256, and keep RSA-SHA-1 and RSA-SHA-256 at the same SHOULD/MUST-level. In other words, I'd like to see an argument that deprecating RSA-SHA1 in favor of RSA-SHA256 actually buy us anything that we believe anyone that will deploy DNSSEC care about, before spending the cycles on it. /Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 09 09:45:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSWb-0002FP-LI for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 09:45:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdSWY-0001Pk-Ja for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 09:45:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdSTO-0006Cg-K0 for namedroppers-data@psg.com; Tue, 09 May 2006 13:41:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdSTN-0006CE-1Q for namedroppers@ops.ietf.org; Tue, 09 May 2006 13:41:57 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k49Df5Fj022779; Tue, 9 May 2006 09:41:05 -0400 (EDT) Received: from unknown(158.69.81.159) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWdaODS; Tue, 9 May 06 09:40:55 -0400 In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9982E5ED-751F-4AAF-8A99-5B7FDA3285FC@tislabs.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Tue, 9 May 2006 09:41:41 -0400 To: Suresh Krishnaswamy X-Mailer: Apple Mail (2.749.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Here's how I addressed these issues in http://ops.ietf.org/lists/ namedroppers/namedroppers.2006/msg00617.html ISSUE 1: IPR, CLOSED Use available replacement text ------------------------------------------------------------------ ISSUE 2: Mandatory to Implement, CLOSED There was one comment received on this which suggested that the text was nonsensically phrased. Since there was no comment from anyone who understood the issue to suggest otherwise, no new text relative to "mandatory to implement" is seen as necessary. ------------------------------------------------------------------ ISSUE 3: Requirements draft has presentation flaws, CLOSED Changes that were suggested to address issue 5 may have fixed this. There were no other suggestions made to correct any specific presentation deficiencies. ------------------------------------------------------------------ ISSUE 4: Requirements draft does not explicitly mention advertising key "lifetimes", CLOSED There was concurrence that the requirements document should not deal with the concept of key lifetimes. ------------------------------------------------------------------ ISSUE 5: WG submission has embedded requirements in definitions, CLOSED Use available replacement text ------------------------------------------------------------------ ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements, CLOSED There was one vote against including non-degrading trust as a requirement. Since no one seemed to disagree with this, the action is to remove "non-degrading trust" as a requirement. No new requirements from draft-moreau-dnsext-tak-req-00 were separately identified. ------------------------------------------------------------------ ISSUE 7: New Requirements, CLOSED * Removed the "support for graceful consolidation of islands of trust" requirement since this did not receive any support * Removed the "DNS response size" requirement since this did not have support * Added the "Time Delay" requirement since this had support. Mike had suggested the following text as replacement for the "Time Delay" requirement: "Protection against N-1 compromise. E.g. you can recover as long as at least one key is not compromised. The time-delay in my draft was a derivative from this - a specific mechanism rather than a base requirement." I paraphrased this as: 5.12. Recovery From Compromise The Trust Anchor Rollover solution MUST allow a security aware resolver to be able to recover from the compromise of any of its configured Trust Anchors for a zone so long as at least one other key, which is known to have not been compromised, is configured as a Trust Anchor for that same zone at that resolver. ------------------------------------------------------------------ ISSUE 8: Wording of existing requirements, CLOSED Action: There was no argument in favour of using 12 months as the reconnection interval. There was no argument in favour of retaining this requirement as such. So the action is to remove "support reconnecting systems" as a requirement. ------------------------------------------------------------------ There were two new potential requirements that were identified in the mailing list: I) How often is too often/not often enough to pull/push/verify status? http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00575.html The following text (again extracted from a mail Mike sent me) may capture the intent of this requirement: 5.5. Detection of Stale Trust Anchors The Trust Anchor Rollover solution MUST allow a validating security-aware resolver to be able to detect if the DNSKEY or DS RR(s) being used as its Trust Anchors are no longer valid. II) There should be a way/method to maintain IOTs http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00566.html And here's what I added: 5.11. Support for Trust Anchor Maintenance Operations The Trust Anchor Rollover solution MUST support operations that allow a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another. Suresh On Apr 7, 2006, at 11:23 AM, Suresh Krishnaswamy wrote: > In a short while I'll be sending out a list of pending issues > (currently 7 in number) for draft-ietf-dnsext-rollover- > requirements-00. All of these issues were extracted from e-mails > that were sent to namedroppers relative to this topic over the last > month. > > Sample text appears in most places. If you don't agree with the > wording in the sample text please speak up. In places where there > is no sample text, silence will be interpreted as an implicit > agreement by the Working Group to close this issue without further > changes. > > The hope is to have each of these issues resolved over the next two > weeks so that the next version of the requirements draft can be > rolled out and last-called in the relatively near future. > > Suresh (on behalf of the editors) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 09 15:54:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYIM-0005iB-Vx for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 15:54:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYIM-0001UL-Li for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 15:54:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdYDg-000GHB-E2 for namedroppers-data@psg.com; Tue, 09 May 2006 19:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdYDf-000GGE-B1 for namedroppers@ops.ietf.org; Tue, 09 May 2006 19:50:07 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k49Jo1XO006261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FdYDZ-0005R4-Fm; Tue, 09 May 2006 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-nsec3-05.txt Message-Id: Date: Tue, 09 May 2006 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 Hashed Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-05.txt Pages : 44 Date : 2006-5-9 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-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-nsec3-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-nsec3-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: <2006-5-9125934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-9125934.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 May 09 17:10:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZTe-0007Ye-O9 for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 17:10:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZTd-0006W9-87 for dnsext-archive@lists.ietf.org; Tue, 09 May 2006 17:10:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdZQt-000MjI-9M for namedroppers-data@psg.com; Tue, 09 May 2006 21:07:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdZQr-000Mij-7j for namedroppers@ops.ietf.org; Tue, 09 May 2006 21:07:49 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k49L7dET016330 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 May 2006 17:07:39 -0400 Date: Tue, 9 May 2006 17:07:38 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b On Mon, 8 May 2006, Ólafur Guðmundsson /DNSEXT co-chair wrote: > > > Dear colleagues > > The Working group has had a document for the last few months that > defines a new DNSKEY algorithm RSA/SHA256. Discussion on this > document has been non existent. > > The chairs would like to ask the working group following question: > Is there support in the working group to add a new RSA algorithm > to the list of supported algorithms? > > The benefit is SHA256 is stronger digest than the SHA1 that is in use > today. Given that DNSSEC signatures are over structured data, it is > not known how much effort is needed to create RRSET that matches > existing signature for a particular name, type and class. > Further consideration is the fact that DNSSEC signatures > have a limited lifetime, restricting the window that a forged RRSET > can be used by DNSSEC validating resolvers. Adding more crypto options requires more software in nameservers and resolvers. Yes, SHA1 is breakable in principle, with a lot of work. But all crypto, with the exception of a one-time pad, is breakable in principle. The only real shock with SHA1 is that people _expected_ it to be one-way. But people should not have expected SHA1 to be unbreakable. Shame on them. Their shock is their own fault. It is also well to note here that (so far as the Chinese paper goes) SHA1 has not actually been reversed, but that the computational effort to perform a reversal requires less effort than previously thought. The computational effort is still very high. As I understand it, it is still beyond the feasible capabilities of most or all governments, much less the capabilities of some group of hackers. Second, the crypto security needs only to be comparable to the physical security of the root DNS servers. If the physical security of the root (or rather the root zone signing infrastructure) is compromised, then one can obtain the keys without a brute force attack (a "black bag" attack). An estimated cost, that is a dollar (or euro) cost, can be assigned to this "black bag" effort and the cost compared with the cost of the breaking SHA1 hash by computer. I suspect the cost of physically obtaining the keys through physical breakin is much less than that of breaking the SHA1 hash. This would make SHA1 strong enough for our purposes. A more detailed analysis may be in order, however. Third, the security of zones below root are dependent on the security of the root. Making e.g. av8.com (or perhaps .com) more secure than the root offers no benefit, since the delegations can be sent to other servers if the root (or upper level) responses can be falsified. The security equation is subzone.av8.com <= av8.com <= com <= . > The alternative to defining RSA/SHA256 now is to wait for efforts to > standardize new digest algorithms by NIST which will take 4-5 years. Another alternative is just sticking with SHA1 and working on more pressing problems. There are much more significant problems with DNSSEC in actual operation than a slightly weaker than expected hash algorithm. DNSSEC requires stateful DNS, and stateful DNS on Anycast roots is a big problem that people are only just beginning to grapple with. I expect that it will take a couple years to fully resolve the current stateful anycast problems, which delays widespread DNSSEC use anyway. So, there is no rush to replace the hash algorithm. > Please give your chairs guidance on how to proceed, if there is > sufficient support (minimum of 5 people) for defining RSA/SHA256 > we will start a formal last call. > > Olafur & Olaf For the above reasons, I think that we have time to consider the correct course of action. There is no need to rush into more algorithms which require more code on nameservers and resolvers. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 May 10 04:59:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkXY-00011D-2J for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 04:59:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdkXT-0002Yw-KY for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 04:59:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdkR9-0004BJ-PF for namedroppers-data@psg.com; Wed, 10 May 2006 08:52:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdkR7-0004B4-BJ for namedroppers@ops.ietf.org; Wed, 10 May 2006 08:52:49 +0000 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4A8q0fm028310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 May 2006 10:52:03 +0200 From: Simon Josefsson To: Dean Anderson Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060510:namedroppers@ops.ietf.org::V8ZQuOL0di8+Y+g8:5z5m X-Hashcash: 1:22:060510:ogud@ogud.com::NyPnGK6O9ZVej3nC:M2Ka X-Hashcash: 1:22:060510:dean@av8.com::2Iu/QUI7Hzfm34b6:Q9+v Date: Wed, 10 May 2006 10:52:00 +0200 In-Reply-To: (Dean Anderson's message of "Tue, 9 May 2006 17:07:38 -0400 (EDT)") Message-ID: <87vesecle7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Dean Anderson writes: > fault. It is also well to note here that (so far as the Chinese paper goes) > SHA1 has not actually been reversed, but that the computational effort to > perform a reversal requires less effort than previously thought. There is no reversal attack on SHA-1 currently. Wang et al's attack find a collision in 2^69 operations, instead of the expected 2^80. I believe the limit has been improved (2^63 in August 2005). For digital signatures, a collision is all that is required though, you don't need reversal. > For the above reasons, I think that we have time to consider the > correct course of action. There is no need to rush into more > algorithms which require more code on nameservers and resolvers. Yes, or at least, we need to document a more compelling reason to do RSA-SHA-265. 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 Wed May 10 10:45:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpwM-0007GP-VG for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 10:45:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdpwK-0000kY-HP for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 10:45:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdpsU-0002NH-GZ for namedroppers-data@psg.com; Wed, 10 May 2006 14:41:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdpsR-0002Lz-Ba for namedroppers@ops.ietf.org; Wed, 10 May 2006 14:41:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C77FC33C3F; Wed, 10 May 2006 15:41:16 +0100 (BST) Message-ID: <4461FB8A.7070101@algroup.co.uk> Date: Wed, 10 May 2006 07:41:14 -0700 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Simon Josefsson CC: Dean Anderson , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= =?ISO-8859-1?Q?_/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> In-Reply-To: <87vesecle7.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Simon Josefsson wrote: > Dean Anderson writes: > >> fault. It is also well to note here that (so far as the Chinese paper goes) >> SHA1 has not actually been reversed, but that the computational effort to >> perform a reversal requires less effort than previously thought. > > There is no reversal attack on SHA-1 currently. Wang et al's attack > find a collision in 2^69 operations, instead of the expected 2^80. I > believe the limit has been improved (2^63 in August 2005). For > digital signatures, a collision is all that is required though, you > don't need reversal. "Required" in what sense? Yes, it allows you to produce two things with the same signature. What is the attack on DNSSEC that arises from this? > >> For the above reasons, I think that we have time to consider the >> correct course of action. There is no need to rush into more >> algorithms which require more code on nameservers and resolvers. > > Yes, or at least, we need to document a more compelling reason to do > RSA-SHA-265. > > 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: > > -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 10 11:12:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqMq-0000Ww-0j for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 11:12:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqMo-0001vD-JZ for dnsext-archive@lists.ietf.org; Wed, 10 May 2006 11:12:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqKs-0004hU-A7 for namedroppers-data@psg.com; Wed, 10 May 2006 15:10:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FdqKq-0004gj-Ed for namedroppers@ops.ietf.org; Wed, 10 May 2006 15:10:45 +0000 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4AFARru022234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 May 2006 17:10:28 +0200 From: Simon Josefsson To: Ben Laurie Cc: Dean Anderson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= =?iso-8859-1?Q?_=2FDNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <4461FB8A.7070101@algroup.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060510:ogud@ogud.com::ehyqJslQC+p/vGVI:8kR X-Hashcash: 1:22:060510:ben@algroup.co.uk::/Br9TIATXRfQdmuz:Yel X-Hashcash: 1:22:060510:namedroppers@ops.ietf.org::TGKFv95xPBjbo15f:lcI X-Hashcash: 1:22:060510:dean@av8.com::w0nS3DJMQvN0iFad:3Fwv Date: Wed, 10 May 2006 17:10:27 +0200 In-Reply-To: <4461FB8A.7070101@algroup.co.uk> (Ben Laurie's message of "Wed, 10 May 2006 07:41:14 -0700") Message-ID: <87zmhpapb0.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Ben Laurie writes: > Simon Josefsson wrote: >> Dean Anderson writes: >> >>> fault. It is also well to note here that (so far as the Chinese paper goes) >>> SHA1 has not actually been reversed, but that the computational effort to >>> perform a reversal requires less effort than previously thought. >> >> There is no reversal attack on SHA-1 currently. Wang et al's attack >> find a collision in 2^69 operations, instead of the expected 2^80. I >> believe the limit has been improved (2^63 in August 2005). For >> digital signatures, a collision is all that is required though, you >> don't need reversal. > > "Required" in what sense? "Required" to break the signature scheme. > Yes, it allows you to produce two things with the same > signature. What is the attack on DNSSEC that arises from this? Wouldn't such a break violate the property of DNSSEC that after successful verification of the digital signature, you know the data you received was the intended published data? /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 carl_wilson@xcelmarketing.com Wed May 10 18:17:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdwzV-0003vx-MV for dnsext-archive@ietf.org; Wed, 10 May 2006 18:17:09 -0400 Received: from [87.223.152.76] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fdwz6-0004Do-3q for dnsext-archive@ietf.org; Wed, 10 May 2006 18:17:09 -0400 Message-ID: <000001c674a9$d8aab900$0100007f@localhost> From: "Richard Young" To: Subject: Your partner will worship you for it Date: Thu, 11 May 2006 00:16:13 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C674A9.D8AAB900" 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: 1.4 (+) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C674A9.D8AAB900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C674A9.D8AAB900" ------=_NextPart_001_000E_01C674A9.D8AAB900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C674A9.D8AAB900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby ------=_NextPart_001_000E_01C674A9.D8AAB900-- ------=_NextPart_000_0001_01C674A9.D8AAB900 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C674A9.D8AAB900 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@caca> R0lGODlhQgIDAZEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAgMBAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTlcHAyeb8VbGOXOXQBDCA/R6233TB1gReECoBsSW2AZQp9HY8mgQOTG5 UllxaWLYQbgJ4/mJEQi6Qwr2mEm5CJOK0WryChGbN9J5Y9qCyzBKpBt197eAuqp4EDdXzJic rMDsvBipCN32djxtnNi8nK3NLelt/a2NjXz9XU6+GoEHjADcx/7O124Qv9dOn8BXX1iYr/+v Xz5794K9q/fvIEKD/oLtKehuoAJ4/R7Ks+jQXcWC/xQrEhSYUSHGi/FGScwYRN6mYeKUtWTp 8qW6lthk0qwZU1pOc+ESoIuJoKdQnjN32jSKdJY/jxrvbeTllJ/Uh/qk7ptKtYEhh/M2Uu1o daLYrF/BNt36NOxSrFOvqrW6ieuCrljlkqVbRKUwnUmJpjOHNOjMnsqi+cU59CZNwogPJ/bp OPLRuQHv1r2MGWpWtF8te5079q1ns24/d2Zq+nRVdpsxs+VHOvOuplU9y0ZtRO84yOfA+Z4s rWjhv+omPV7smxnOwI17h4MGtPGzctvIDTp70TZUzWbVotQNsPJ22qrBJ7Q7/qnCuBZb2yYr 0Gvp0uThra+P/f4R8IJ3G//+SVgrjKWz12RAPeMAgEUdJ9g0wg3Y23ISRgdBerW1dRZt3Z3G Wmr4XajaaB6adpWFIdIHW3uiaaZRbCKChtuJH7KHhEi83YgMgUf9xEgDARq4Y3HE/CbJbswF aYyEhi2m44GKzWLifPK5tmGJGJJI3m1asvialTFKCV9aX2Y5JW4Mwbiiay++5csQwSHXSJzT RdiNkAruxU0deg7mDWQOPgiYcnsWSOeECBYmnAPZLeQio2W6lyGkNkYknkidSNSQfVxhytGj 2XnSKD5ksmWjqGEyahI9l3bYFqdtHgLrE682MSsZtT5wa6y67hqaFrmC8atWvA5LbLHGHots ssr/LsvsC216Oaqvwc6GAo3NXostZXatI9prvpIwrQThepttuWWYiGu3p2YxLpqaeNCuufI6 wd55KIXY6raaWrtvmR/BFpKrn63HaWf23tupo1eGx9AfbvU74rwSbxFXR1yiCKbFZGo8ZlQA dQwWZ2uW1fHGkYa5Hccykjtxy+wWDGaMaaaoZnxa4uuvhu3xe/LKXKKss7Urq6idy0aHkfGi 6sbMKn82j4xiZouyxqrOIPdc8b4hUTsz0eYdDXYXGSvaJZWQCusiujmDRjWaUd5MStREzxi0 h/GGjXcOb7+Hc8zvgUo3QuTuvfCFFp7JZtxbhob439HmDTmtMGc6lsiT/64KCuaU4kxlQBvW Ze/QplKaasjaDg1fqZGvzvq6rb8O++t3x0577bbfjnvuuu/Oe+++/w78xEoZGcPwshhv/Ayv JN87wulOMbslfCaYqGLESz8hHdUfb8Ty28cwa/QrzJ6r+DV83kNyjnxfPPvrZ8B8EPGXEH4S 5ItCBfqfVHaOdYVak6dtKKhPDRrSTvZUjWJQZ0h9Ug6i/lQTOTWJL86ZIDX41MDfJLBJD+Rg hSBCOYCVDlUYUdin+BeyyZWwRQGTi0qo1kKKxFBhKwTJCGVjEBSexHmWAiEJWWYHpSWpGhTq C5CQVMShZOM4F2yOEYu4HCVK8ImPkeL0qKhAyf8cSVwqI9nMTEItFlkOboKbyOfwAsYv8swj FbsaGyOWMiy9sWvmu4DTikTEBWoRgVVc0GGQGMU9AsZIDOoPFpEIIUQOso9HDGHgvog1YTlO LGnr2YdqI8ZIrquS7hpbyTpZM6iZzQ9CLNIhT3nKYVSHOE8yICoJiJxGpjIyq/TPnxjDyAMp JWX6gUsvU/fLO3pNk4BTj6ouWZZfWk1dZByZDx+Jsk9p0nVBnJQpc5nLWV4vOjAJpCJvZMgn 2vKbWzTOH5UkSHByS2Y3e5Qo08VJZr4zk+zc5Np65Ul5igx13iJcHe3Ivx7hKJ26JGc4F0kM Jt1JnNZbqDnJyUTrARL/oQaVqCQh6UY1+a2YW5Lb3uiJUcZZ8p7l8Sg+Q/nRtXSPkKsMEACz WUBDZZA6unQoLLlJJJYutIP/SxQFEYVODvLFgRUqlQoTthBgDiSHzlNqqjjHkdLRZ3SbKVh9 rOqp0M0noD1MTVfzdbbgucF9hPrBP98FgrOKda0oIKoqUrIfEaiVrXStq13vite86tUF8yvr +yTQV8CSdXwciBe02MUsoRHrTdQTQWAvwaMTBBag1tSA4iZgizxUtrB4U6wF5uqDyBYBsoMF wWQ/Sz+yYRZE8HpcBkB7LnfZ8Qqb5dGhgFooPzFQqAEETgCXyMDgAgpOrkwMLm+q2o/REISH /1MVwRAGLYiZEboa2uFISBdVGv7LYDzc4Q1LeJCDZRW6wXRkSUhYEoc5EqmwdVYpCzrQVjY0 UH5U6Dl9W1GI0nI4hXxer8zkzK4BjUPulO087cPOzJURk1XCDshMF1KoNpPBGfWZgaEgTMZW 8EgQculf5BuYoRZXi4bEJkEhZM2vVQ5EUdvoiuf2M9bOE5osMynfZlyyLuYTlDe2cIVbbIUM N9GJNHWOHw9VSBPHEpUx1a8i3XpRwymzucfM1L1KhDnyVkqFILWqNGH0M92kVEw+ButJtVPe A1tqa1UQ8pIHlMjsMVmb8IWpBZ3MUAoUE13pIVwYaQbEGwvNxZik8f8n+0nMZe54n80cc4Td RtuA2hTEOQLniIFD50lvEbeZJnFp93yyph2W0JF6mMnkyGKNvridh8YxHTN6ZcY9bNGNPnUZ BsXTlza5TgedjnCJu9sFOvF6txWxb3c5NSs3ZNmzXuo8qFue9ZKO0eadUeiya88ef7Wq25LU ek212dGJO80Q0RS3pUvNsJ2WWO3dKyfcPQLkTqyp8C5Fve+N73zre9/87re//926ddMgzvIr bQrkLVmDRwC427yBwC/w8FWHorUlwDUcFB7aQY4W4xXnuAcELloo2gDkBo+4jFHr3ygLouPh 9CsTTA4Jj8db5toLQSZgXnPTlpzm67TsB1P/vnJRSFpId+ZpfHuKDl3zRuk9lUlyfHrTnyJZ 4xvmdK6HLCjkClCVwSUyfUPOaV/fsqbCrnrYtf50O/2n6xvWyQbPvlqmfhfLzt7Kc58td696 d9qvfS+ulXz0Kb50yHh6O0zgfF914rnDJx67nfNMaYKWuL54lDzgI0pwOh9U825PvFYaVWqJ 71Nt9XSwgAfh9+A0fpwUYlAl/v5r5uy0gJS/fO1X7/X5NlLwbA9xLWVqUNsDKZHGhjzvJ0r0 TXNN290CvapdJ7cf972ysG8p1V0qXI1HXe2AH46RWT/577sEOoe/JYkfaH7WmzP7Le8+8F9J y95y+KeLp3zufR/+/yJebtpaE/Ad6Zll/ZRmMcZF1Jd85ad7rXd9w6VOCIh/cjZs9+cn/aN+ t3cT3UQomUd8RPJ4xydOHXhfpIVnLcd5B0h1UTZobHJyyERoozdhlOUJsJckxqd9gSJRGFhp 7uckR5d/lYZTGWiDDJWDCRV42/MjnZaAPdJ92eRpO9iD52dfwWeCFsVjGIUxtvZOS5NoCzZz vTZA68d0cOdBrcRH8dd7umWBuWVxaMhb8teGUAd2WbdTFFR8ulV0HlZ1U2dBYPhH9Id0l9Y/ cgJ2y4dU2EZ3m9JdeLc5hqgtjWNu7fZWdIVzAEeJ3CNWUFaJmaiJm8iJneiJnwg+PvcFpv/w K9MSLL5QPtfxX2rgWUpAb/gDLKJIiBgGdCcAiak4WxGjA5BYYK4ILkgjixdGL7WIViyAiygX aHoTirrYC7/4Mi40Q9p1GSdEXeK1MNK1Xez1TO81NXXnQ/tgjSRRbSgkQmwTjT+kaCKkXuSY L5X0HdvoXeEFj9AIaWEhjux4bjnzjtbobQwjjUxxMLw4A2hUNqjhZ3YHaw/2c+iBhfnEMd0m fR7DGRApkS94jSvSYBGGFxHhVQuWRj6jYFeyVahGax7DkSF1RiRFkD1GW6zWZ9M0YK/WNqwG ZjBZayIZSmXGTzvpaKfSNjo2Kk2zhWdWaO60Y2wzTJO0Gio5ONP/9JNc05N+E2TkxmVwU0r+ tDNWFn1fdnqu9pDVVWUaKXpnJmZBmZX+h5Q3SZRcOUllSTYziTr1wpTZ5ksn4TXiNpQ7CT02 6WN+xmPccZY+uXwlCU2m5h15SZitRnox9pRoSUlzyVE6CYDCGB9CqZQtApmD2ZRwaTiImZNS 4Jd9uRYgNZeFQ3peaTkOaZCemYWKOZQ8VJp0uSaNU5jPh5JQCZOR2VxN+Un6E0+O2CrS4lze WG1JZW6FqGzS1h3bxjBMo17TlY8XKTprJmrdNpEbY1QtRJfc8Zy8+W3PCSrZSZtUhY12M14s qTnM5p3RSWb4pFWdUzWsI5D7dj8TlwLz/wmKyZifq0ULzkJY+wmgASqgA0qg/3aM/2kHaYWf Bcqg9uafFMcDC9qgASqQhuUDEjqhunJe46gvOnQm3ZiIMhRDWVOedIRVGyqNYmZd4XWOKPqN CZGhvMOQc0RgKjdgBEijUhmT0cZ80aSQpumR7ZmjGAKYMao7USlPBdmepGiROypDvdg3rJmF KelMRWqkuMNLYVlS4Ql6wsSWOvqiqjNetDkaX1qaKaSlU5VsV4qlIxVgl7WcKZeYEoeZaklS nuKUEZlZq8imsIOkO/piLphqswmnoRacbyqlWCmWrYGjfeqn4rk2ldVVIMqlwGmc0zV3xnRu GAOpGnVUaGqpYf/aqI4KORjqBaZKqvqGqlywqqnqqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrOYSANEqrdNKrdVqrdeKrdmqrdvKrd3qrd8KruEq ruNKruVqrueKrumqruvKru3qru86riAAr/NKr/Vqr/eKr/mqr/vKr/3qr/7aAf8qsANLsAVr sAeLsAmrsAWbAdZqNNQ6BhD7BBJbBBS7O9XasNMKNhb7BRy7BB4bBCCbOyL7ABh7NCSrBShr BCrLAyxLOyZLAS6LLTJbBTQbshq7sjj7OzYLADD7sDoLBjz7A0JbA0S7Oj4LAUjbMkb/WwuQ yLSaxQFPGwNSizdK6wBWKzFPK0wnuQtOC7Tr8F5CF7VfC7YrWAJUGzZYywBqK1d7igVai2Cf pyheK62op1KAEC5CC6MsgLYba7Nsq1mjCgVwq1J3p4jYtlybNQE8uynf6VxlhIgI1lR6W5Ha RReveLVke7F/27fc0qGNm0PYNbSai1lxe5KNCzCQe7ntwrhxG7pR8bqve7qKS7nosbqqm7F1 CzyAmwC8+wEfgZDl5jC36wOE65EEc7ewS7yYKwGtu2a4q7zQa4i4QLmwC72x+yud+7Oku7ba +zyIc0LXu5E7ALfPG71ceL7mwbwly71da5IqKr7xa5Ldq7t6/7YUy9sh2bi47Xs7vnsA/vtu goO/4qu4NmC8yiW730G8lLEBrXu8ZiS/2Iu+C1C9TrHAw6kB3ru0nMu/aXW/EbzAQHDAs/vA qXu+wNTAHaxcJzzA6RvC9ButyMhcaPSRF6DBEwPAPXvDgynBLhykxavCctuIx4m8EkmcGRzE d5t3yTm9yYm5FXy8AcO1NpzEsJPDORx0UdzDkSvCVTwFOwzBJwDGJjDG0MrB9bu9MSwGZVzA H1DGJPDG2XLFcVwGdNwDdpwCeOzGXtw6c8zHyqLHOhDIZPzHNDDIyeLHhXwsh3wDjDwCjpy7 auw7Dru/kJyyiuwEliyvmDy1nJy2if+syVYQyp2MxkwwyjHryWl8xgvLyq3syq8My7Esy7Mc rqhMy7eMy7msy7vMy728rbbsy8EszMNMzMVszOoKzMeszMvMzM3szLKczM8szdNMzdVszeka zdeszdvMzd38zNnszeEszuNMzq8MzuWMzgYrALo8AOnszrVcyd0qD9F6B+H6Du4KDMRcz9Ka z+a6z9jazwh7zwEwz/T8z9ca0AXNrtJArWwwrYqwrRAtrQzdyipBrwc9ressrhrNsPG8rf+s 0RjtrSKdriSdywNN0Ots0iPN0QDd0gW7zyFt0DO90vUc0y+9rg4dre080TodADrt09YK1Dz9 00T9yhyN0+3/mtTCfM7WitEKjdIondIurdJIndADbdMhfdUpXdUr7a8gXdVOndX83M9QjdVX DdYBPa8mfdNTjdBhzdVLba5B/dA+PdTZetc7nQiwrNJk7dZcndFeHdf0/Ndb3dZp7dcHPdbz 2tRi3dKKrdVuDdbZms9PDdcEbdAiPdaVHdkHO9lsvdh+/deFTdNwvdiCXdJqPdNTXdOmvdo5 LdE7XdQ9rdd4zdN2XduurNaKzc+E7dtO3duSndGB7dsxPdyiLdOj/a6N7diindmcHdVyLdla zdnVutv3fNgKDdNWrdzITd1t7dyJ3dXQLd34DNmB7dVS3d3pKtG3bdQUja3wTdu6/43ZwU3W Za3e1JrQ9l3fv53c/Q3gSO3f9crcb/3ayk3S6R3Z2W3d+F3aD76wn73UDD7dxK3fYZ3gqn3R j43TqG3Z7UrUQx3b8x3RRp3bFW3d+p3i3/rfj33c9S3g/B3jMc7YHq2t3C3cIE3aB97gGL7g M+7jD17dv73d4v3WQV7hmK3jrH3Zpl3eJX3gHx7er93ZOU3iJ37ls12tuI3lEb7i/E3kAB3c NB7gYy7jL97iBG7jlC3VaG3VN53fEB7XWQ3npY3dTo7a+WrRgG3gaY3fb07dgH3WGv6u6o3Y Fp7ZF/7k4irfFD3iWP7oj66w1+3m9y3Xgy7ogw7olt7VfP8e5+xa4F+96Oea57Rc6rw86gpr 4u8ssB1O6mrevBH+6aRO6Kg+68Gc6gm76qzer5Q+rrUO6mvO68NO7MVu7Kt87Mmu7MsuzqHO 7M8O7dEezM4u7dVu7dfOytSO7dvO7d2er9ru7eFu7S+05+IOruBu7une7bmu7uiu7u8+7vDe re4u7/W+7Oye7vRu7/te7Phu7vrO7wH/zv4u7gAv8AdPzgQf7gaP8Nys8AO767r88N2u7WZt 6Z596gnr5hMv2MD+r23O4SF/434+8UW913od1JK+5SeP8nS9riW/7dS+5AaO8Sft5Kn90TDP rsY92BAe2g2e5OfK5Xmd19da9C7/r9QNX8Us/tKG/uaZXucZ3uQb7/OGTec6v9F4PuGhremA /t0X/9xYz+ZibeRM7tLTnfFGv+pE7962feIqr65iX+0VL+XhvdmdXdlHjuBN/txAT+dB3+vJ DdqXvdrnXdxIftpyf+RN3+E/fvY8n/Yrz/Js3+UN3fayreX4rPSlzL5Mz+EXTtxXD95nj/Y/ n+icXuHlzq+avfWFf9aIbuQWfevm/fmwf+tOj66xDd/yLdSSjvRQvvkB4O6TDftKzuPrbeGJ 392vb/bN3+pJDdpVH+WN7/zorfhjb/fQ/+R1P64hvvbf360u//voev3QLvPOzf2eDuQjj/h8 b/YMPuQA/67nTX/8ia78Ob7+XA/48FrlBBAp8pIVeTXzjJMXy8HGbv0CP08jTTJLVWht3ReO 5ZmGgRvPdSA+fMeHCEYmlCCQeFkQh8Jf0dKcTIuU2rVqTEqW2iMUCYR+h9jeM+t8oi2QLbvW kXPmdNFodE/IUWaM1S9QcJAwZucQp1BRCXCRyhGyYSuScqWxcrAPM/Jy0/NTEBER1Kxs8Yt0 0DR1s5NVRvM10FW21lb00FZ3l7fX9/eX1g3VcVKhRvg0OQN3B/gZOlp6mprrxahyeVr7olmn GjxcfJzcT1vI7ZENjjHCaTjd/V0syqorZW0+qsY7p/wfYECB1M4lMciiwrEM2P+o2JP0ACJE SQ8VRsSH0F1FbhL6JRr4EWRIkZTOJVQ4TB67hwxNtmTI0iVGhAvXyDwpo+ONkTt59vRp6ZoS a0NhSLzpsOLMmElvEjWaEKahnD+pVrU6sCTRpi0vMl168ilSsGMX2oSqVGrHq2vZtoW2bB0q uSrDjOmSjwmaMj/w0mpyF8lGBjl5uDV8GPEnwb0aLRZai3BiyZMpzyoX1zEYyFMrd/b8uSxo WZFFlzadOPNpM6RVt36V2lasf7Bdz2B9jdjKxsaw0A1pkPcZS8FlEQNuj7jmVVf4oNBDJ4/s 6NGl96jt6XYLJiqMJafhPaBefciSgQeVsUo8i8HvPTL/c8cDnxDw41cXQZ8QbU4E9XPkjLsd 5Cjqrr30Aqunrin48m0XfQpcSZ2+vEhpQpT60+6SvBoaj4t5cqPhOehKOGEP++qzozrrrvuj kOyG67CNCDXrkMMCI5rkngVjBMZBDuF5w6J0NFJwvSBJguM49fDxcEcQ5cPjgwDwk9LEEjmw 0pwr8olRvAhTotGLJdGBh8g28gLkwsH+c+GuLbk0EsYNdaRRNw/VYLAWIx+kSE55+BzwzjbP A07JBP9Asr8nsdxjUSrrSKG5+Sz7ziaWtJjoKEzP2oqFMV8y6iWl0kzARe6KfFNI3vxcdTc/ y3xVGilgjbM9V5ssk0DzBCEU/8E/l4yTOREbbU6TEDMI0dgZMlvluO001Uq5Dzs1iQyzKkTL j1J/fVXDejrRkVWM3gl3Tq54vFTVHIPMyFl1O4UTEjg15PXWdmkjUVgo9W1UWHxLQebQZ9H6 NjS4KgiLrFAzJURbMa+VFTBGvFzwSyKPqBVPXeZyxUZTxPuS4ht1LeVjvMgUkp6TmVOUWBTr Q9a5R0tMVlmAh4qqKZjEeoq7gxOuFGFsV1szz1G3/Wnk2f5JUZzULtZTwpM9xuxbiP8CA+OQ 02x40IzJS/oyaX9beuwVK+Ha7LTVfsbotRtA2+245U6lbbnhnhvvvOPVOxSi+f4b8PwCx+Lu wQ0/PP80xNPqR/HGHe/q8RYKj5xyvOsu6ruCMOxl8so9X/tykjDXjnO/Pz/dcla6bFZTW5dQ +XVeOkeddtVCZ5PPoBfeFD3eb7fN9NqFX/F3oGbi+VmFoaqW01dmH76z4iFhOhzpIae2+Z1/ dqp0tYoiA08crcdtfBmi7k0Yr0nZ2EKVD51Qv0jzdTRmmlGkblLVWydr4d6Rx152wftVt44W DbBhgl4k25wv0IMxGLHHToKAz8xihqX7VIlK8/sX3Z6mhpQxy059ad8uZtcx3RzIQFkQw19y NbERZg1dglIEkNLVIwrBL0EbO6Cy0BTCGA5QZH5Ilh4uaEEM0sd+KoJeCXv/FDD37MiBOXri CnuoDkMhaE47NJW9aFIjeX2KWxHMBjsaeCqaNORWsFDUsE6UQTceq41S4pfNlijALgrohbsB FBbRQSAzPa0dddpQGmboxTP26YsSa5MMPREXiV0RTMDCwhqfIz/6pciSGqQU9ALAxEcOcoqE IlcfM2TGPRkoXLMq5BPT1StbhXJcpdRi5lDmqyl+Mo0x8NcbSyApF8Asf8PzJLBc5T8BjfJg sgyjFXF1qnK1rVa5BNe6JMJFG4FSdNgcUi3FJ6735MtYwNxXvzRZM052Toc3vFFgPCih15HR hiGjxyJjCcldJemMZzJZXSiGSrEVUp9hShkUaShE/5bJj5IyY2MlFaolTnbSjrOR3iyPVJXy FYJ64Lhoa563jX+SjKKc+ChWyAaSjaqmow9VqVtOepqUrhSmVmmpaV4aU5v2ZKalqelNeapR Fi5HeDvt6VCJWg2hFhWpSe0e45TaVKeOgzCFeepUqfqLqEq1qlnVKiuuitWtfhWsjuiqV8Na VrMSbqxkPeta2cqMtHqkrXGVK0Tf6o+53jWsddXrXvnaV7/+FbCBFexgCVtYwx4WsYlV7GIZ 21jHPhaykZXsZClbWcteFrOZ1exmOdtZz34WtKEV7WhJW1rTnha1qVXtalnbWte+Fraxle1s aVtb294Wt7nV7W5521vf/jQWuMEV7nCJW1zjHhe5yVXucpnbXOc+F7rRle50qVtd614Xu9nV 7na5213vfhe84RWvcgsAADs= ------=_NextPart_000_0001_01C674A9.D8AAB900-- From owner-namedroppers@ops.ietf.org Thu May 11 10:19:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeC10-0002lQ-7z for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 10:19:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeC0s-0003au-Me for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 10:19:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeBtv-000KgE-RV for namedroppers-data@psg.com; Thu, 11 May 2006 14:12:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.1 Received: from [216.127.148.222] (helo=mail2.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeBtu-000Kfx-3M for namedroppers@ops.ietf.org; Thu, 11 May 2006 14:12:22 +0000 Received: by mail2.sea.safepages.com (Postfix, from userid 1012) id 3130B680CC; Thu, 11 May 2006 14:12:20 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.15]) by mail2.sea.safepages.com (Postfix) with ESMTP id A11A967F0B for ; Thu, 11 May 2006 14:11:44 +0000 (GMT) Message-ID: <44634629.4050500@connotech.com> Date: Thu, 11 May 2006 10:11:53 -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 Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Dear co-chairs and wg members: I regret to post the present message against progression of DNSEXT WG document draft-ietf-dnsext-rollover-requirements-01. I see two difficulties with this draft, related to the IETF document development process. The wording used in the section 5.2. (No Intellectual Property Encumbrance) is such that the DNSEXT WG commits itself to make factual verifications about the presence and/or validity of IPR claims, which is a WG activity not compliant with RFC3979. The other issue with the document is that it goes beyond the DNSEXT chartered work. Specifically, the charter mandates DNSEXT to "Define a method for automated rollover of trust-anchors configured in validating resolvers." Instead, the requirements document address trust anchor key management on a broader perspective, as if the charter might be revised as a consequence of revisiting the trust anchor key functions in the DNSSEC protocol specifications. In going beyond its specific automated rollover mandate, the DNSEXT envisions solutions outside of DNS protocol extensions, again in possible conflict with the DNSEXT charter. There might be a group willingness to proceed along the lines explained above. However, the IETF standards development process is a structured activity, and wandering of a WG outside the process rules and/or its chartered work may be coerced by the groups in charge of IETF activities overseeing (if I understand correctly, this would be the IESG if and when the draft is approved at the WG level). What should have been done in the preparation for a requirement document for automated trust anchor key rollover is to define the very issues as faced in the DNSSEC protocol environment, contemplating the set of possible DNS protocol extensions for rollover purposes, with the known limitations of the DNS architecture. As a consequence, the requirements document might have come to inescapable security considerations expected from any trust anchor key rollover solution. If I recall correctly, the WG chairs expressed the view that the requirement should also define "metrics" against which trust anchor key rollover solutions would be evaluated. These issues were privately raised to the DNSEXT WG co-chairs, without feedback. In WG discussion about the previous version of the document draft-ietf-dnsext-rollover-requirements-00, I expressed my opinion about the section 5.2. (No Intellectual Property Encumbrance), and I otherwise abstained from making contributions towards advancement of the draft, based on the assumption that the WG discussions on a draft going beyond the WG charter would be unproductive. I leave it to the WG co-chairs to handle the current message in their process governance duties. 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 May 11 11:52:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDT3-00059m-Rl for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 11:52:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDT1-00084e-A2 for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 11:52:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeDOF-0000mT-Oi for namedroppers-data@psg.com; Thu, 11 May 2006 15:47:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeDOC-0000mE-QQ for namedroppers@ops.ietf.org; Thu, 11 May 2006 15:47:44 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 9808C11D47C; Thu, 11 May 2006 08:47:40 -0700 (PDT) From: Wes Hardaker To: Thierry Moreau Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-01.txt Organization: Sparta References: <44634629.4050500@connotech.com> Date: Thu, 11 May 2006 08:47:40 -0700 In-Reply-To: <44634629.4050500@connotech.com> (Thierry Moreau's message of "Thu, 11 May 2006 10:11:53 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >>>>> On Thu, 11 May 2006 10:11:53 -0400, Thierry Moreau said: Thierry> The wording used in the section 5.2. (No Intellectual Property Thierry> Encumbrance) is such that the DNSEXT WG commits itself to make factual Thierry> verifications about the presence and/or validity of IPR claims, which Thierry> is a WG activity not compliant with RFC3979. Suggested text to fix this if the WG deems it necessary to fix. I don't think the requirements document is ever going to be a legal document, and thus I doubt that it needs the level of word-smithing we're talking about. It's a technical document to assist technical people in coming up with a reasonable solution ta a problem. But... OLD: 5.2. No Intellectual Property Encumbrance Because trust anchor rollover is considered "mandatory-to-implement", section 8 of [RFC3979] requires that the technology solution chosen must be unencumbered or must be available under royalty-free terms. For this purpose, "royalty-free" is defined as follows: world wide, perpetual right to use, without fee, in commerce or otherwise, where NEW: 5.2. No Intellectual Property Encumbrance Because trust anchor rollover is considered "mandatory-to-implement", section 8 of [RFC3979] requires that the technology solution chosen must not be known to be encumbered or must be available under ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ royalty-free terms. For this purpose, "royalty-free" is defined as follows: world wide, perpetual right to use, without fee, in commerce or otherwise, where -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 11 22:35:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeNUj-0001xu-Jq for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 22:35:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeNUg-0004t1-9T for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 22:35:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeNQ7-000DZB-IW for namedroppers-data@psg.com; Fri, 12 May 2006 02:30:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeNQ5-000DYQ-0T for namedroppers@ops.ietf.org; Fri, 12 May 2006 02:30:21 +0000 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 11 May 2006 22:30:16 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006051122301621269 ; Thu, 11 May 2006 22:30:16 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 22:30:16 -0400 Message-Id: From: "Loomis, Rip" To: Hilarie Orman , =?iso-8859-1?Q?=D3lafur_Gu=F0munds?= =?iso-8859-1?Q?son_/DNSEXT_co-chair?= Cc: namedroppers@ops.ietf.org Subject: RE: Standardize RSA/SHA256 ? Date: Thu, 11 May 2006 22:30:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb > Without a risk analysis specific to DNSSEC, I cannot support=20 > standardization of RSA/SHA256. >=20 > Hilarie I feel as though I should ask, "What is this 'risk analysis' of which you speak?" but instead I'll: 1. State that I think RSA/SHA256 is worth standardizing now. I was perhaps one of those who helped convince the author to write the specific document being discussed, so I'd doggone better support the idea. 2. Agree that I think it's worth clearly stating why, so that others can review and have their own thoughts (now and in the future). 3. Agree with most of the points in Mike StJohns' recent e-mail on this in which he pointed out that it's not really a single question "should we standardize this" but a whole family of related questions. I think it's probably worthwhile for the WG chairs to respond to that mail. 4. Ask whether a risk analysis specific to some $protocol that is in a form which would satisfy the above specific objection from Hilarie is readily available so that I could use that format as the starting point to write up a something. I think I could do one from scratch (perhaps poorly) but I'd rather have a better idea of the desired endstate. --Rip (And yes, for Olaf/=D3lafur, if I care enought to start writing text on this then that means I should bring the last I-D I was working on out of hibernation first unless you think it is OBE. Please advise.) -- to unsubscribe send a message to namedroppers-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 May 11 23:10:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeO3L-0007st-Cp for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 23:10:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeO3K-0006X2-Rs for dnsext-archive@lists.ietf.org; Thu, 11 May 2006 23:10:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeO08-000FPp-Sc for namedroppers-data@psg.com; Fri, 12 May 2006 03:07:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeO08-000FPZ-0G for namedroppers@ops.ietf.org; Fri, 12 May 2006 03:07:36 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k4C37FpE032714; Thu, 11 May 2006 20:07:15 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 20:07:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67571.288D2BD2" Subject: RE: Standardize RSA/SHA256 ? Date: Thu, 11 May 2006 20:07:09 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2C5A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standardize RSA/SHA256 ? Thread-Index: AcZ1bOR7Khl4RmVjQjytvd7S2EZlmwABEQMa From: "Hallam-Baker, Phillip" To: "Loomis, Rip" , "Hilarie Orman" , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= Cc: X-OriginalArrivalTime: 12 May 2006 03:07:10.0059 (UTC) FILETIME=[28A983B0:01C67571] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is a multi-part message in MIME format. ------_=_NextPart_001_01C67571.288D2BD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In other words before deciding to fix the exhaust consider the fact that = the clutch is slipping and the big end bearings are about to go. -----Original Message----- From: Loomis, Rip [mailto:GILBERT.R.LOOMIS@saic.com] Sent: Thu May 11 19:36:37 2006 To: Hilarie Orman; =D3lafur Gu=F0mundsson /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: RE: Standardize RSA/SHA256 ? > Without a risk analysis specific to DNSSEC, I cannot support=20 > standardization of RSA/SHA256. >=20 > Hilarie I feel as though I should ask, "What is this 'risk analysis' of which you speak?" but instead I'll: 1. State that I think RSA/SHA256 is worth standardizing now. I was perhaps one of those who helped convince the author to write the specific document being discussed, so I'd doggone better support the idea. 2. Agree that I think it's worth clearly stating why, so that others can review and have their own thoughts (now and in the future). 3. Agree with most of the points in Mike StJohns' recent e-mail on this in which he pointed out that it's not really a single question "should we standardize this" but a whole family of related questions. I think it's probably worthwhile for the WG chairs to respond to that mail. 4. Ask whether a risk analysis specific to some $protocol that is in a form which would satisfy the above specific objection from Hilarie is readily available so that I could use that format as the starting point to write up a something. I think I could do one from scratch (perhaps poorly) but I'd rather have a better idea of the desired endstate. --Rip (And yes, for Olaf/=D3lafur, if I care enought to start writing text on this then that means I should bring the last I-D I was working on out of hibernation first unless you think it is OBE. Please advise.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C67571.288D2BD2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Standardize RSA/SHA256 ?

In other words before deciding to fix the exhaust = consider the fact that the clutch is slipping and the big end bearings = are about to go.

 -----Original Message-----
From:   Loomis, Rip [mailto:GILBERT.R.LOOMIS@saic.co= m]
Sent:   Thu May 11 19:36:37 2006
To:     Hilarie Orman; =D3lafur Gu=F0mundsson = /DNSEXT co-chair
Cc:     namedroppers@ops.ietf.org
Subject:        RE: Standardize = RSA/SHA256 ?


> Without a risk analysis specific to DNSSEC, I cannot support
> standardization of RSA/SHA256.
>
> Hilarie

I feel as though I should ask, "What is this 'risk analysis'
of which you speak?" but instead I'll:

1.  State that I think RSA/SHA256 is worth standardizing
    now.  I was perhaps one of those who helped = convince the
    author to write the specific document being = discussed,
    so I'd doggone better support the idea.
2.  Agree that I think it's worth clearly stating why, so
    that others can review and have their own = thoughts
    (now and in the future).
3.  Agree with most of the points in Mike StJohns' recent
    e-mail on this in which he pointed out that it's = not
    really a single question "should we standardize = this"
    but a whole family of related questions.  I = think it's
    probably worthwhile for the WG chairs to respond to = that
    mail.
4.  Ask whether a risk analysis specific to some $protocol
    that is in a form which would satisfy the above = specific
    objection from Hilarie is readily available so that = I
    could use that format as the starting point to write = up
    a something. I think I could do one from scratch = (perhaps
    poorly) but I'd rather have a better idea of the = desired
    endstate.

  --Rip

(And yes, for Olaf/=D3lafur, if I care enought to start writing
text on this then that means I should bring the last I-D I
was working on out of hibernation first unless you think it
is OBE.  Please advise.)

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

------_=_NextPart_001_01C67571.288D2BD2-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 12 05:02:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeTXn-0005mq-Cd for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 05:02:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeTXm-0006cC-1I for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 05:02:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeTT0-000APo-8R for namedroppers-data@psg.com; Fri, 12 May 2006 08:57:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeTSz-000APD-4s for namedroppers@ops.ietf.org; Fri, 12 May 2006 08:57:45 +0000 Received: from [213.154.224.45] (fable.nlnetlabs.nl [213.154.224.45]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k4C8vgsg082446 for ; Fri, 12 May 2006 10:57:42 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <44644DBB.3080605@NLnetLabs.nl> Date: Fri, 12 May 2006 10:56:27 +0200 From: Jelte Jansen User-Agent: Mail/News 1.5 (X11/20060309) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> In-Reply-To: <87vesecle7.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA08124CCCBB5B07A498CA45" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA08124CCCBB5B07A498CA45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=20 >> For the above reasons, I think that we have time to consider the >> correct course of action. There is no need to rush into more >> algorithms which require more code on nameservers and resolvers. >=20 > Yes, or at least, we need to document a more compelling reason to do > RSA-SHA-265. >=20 So why is this an issue for RSA/SHA256, and not for draft-ietf-dnsext-ds-sha256-05.txt, which also makes SHA256 mandatory? btw, both drafts don't deprecate SHA-1 but do assume that SHA256 is stronger and contain text about downgrade attacks based on this assumptio= n. Jelte --------------enigCA08124CCCBB5B07A498CA45 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZE2+4nZCKsdOncURAvDcAJ40V2cezT7ZUn5+6SlTdqMlIy5EZwCfROyg QLzm4D1ig1D9W0g+c9kIwuU= =tRdi -----END PGP SIGNATURE----- --------------enigCA08124CCCBB5B07A498CA45-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 12 05:58:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUPm-0002wk-QE for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 05:58:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUPl-0000pn-9g for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 05:58:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeUN8-000EAa-V3 for namedroppers-data@psg.com; Fri, 12 May 2006 09:55:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeUN4-000E9g-Ut for namedroppers@ops.ietf.org; Fri, 12 May 2006 09:55:43 +0000 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4C9t6sY006505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 May 2006 11:55:07 +0200 From: Simon Josefsson To: Jelte Jansen Cc: namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <44644DBB.3080605@NLnetLabs.nl> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060512:jelte@nlnetlabs.nl::QNiohHBTV4FDGlxb:7Mmc X-Hashcash: 1:22:060512:namedroppers@ops.ietf.org::vuIN/3JhCGksX6A4:vdTG Date: Fri, 12 May 2006 11:54:56 +0200 In-Reply-To: <44644DBB.3080605@NLnetLabs.nl> (Jelte Jansen's message of "Fri, 12 May 2006 10:56:27 +0200") Message-ID: <871wuzbma7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Jelte Jansen writes: >> >>> For the above reasons, I think that we have time to consider the >>> correct course of action. There is no need to rush into more >>> algorithms which require more code on nameservers and resolvers. >> >> Yes, or at least, we need to document a more compelling reason to do >> RSA-SHA-265. >> > > So why is this an issue for RSA/SHA256, and not for > draft-ietf-dnsext-ds-sha256-05.txt, which also makes SHA256 mandatory? I suppose it applies to both. Changing the RSA signature algorithm also begs the question: Do we want to move to RSA-PSS? See PKCS#1 2.1 in RFC 3447. I believe RFC 3447, and RSA Labs has encouraged a gradual shift from RSA-PKCS#1 1.5 to RSA-PSS for a few years now: http://www.rsasecurity.com/rsalabs/node.asp?id=2005 One advantage with RSA-PSS is that it is easier to analyse theoretically, and there are security proofs for it. One disadvantage is that RSA-PSS requires entropy during signing. > btw, both drafts don't deprecate SHA-1 but do assume that SHA256 is > stronger and contain text about downgrade attacks based on this assumption. Ólafur wrote: Q3: My personal opinion not speaking as a chair: If RSA/SHA256 is specified then RSA/SHA1 should be tagged as "Not recommended". /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 May 12 10:59:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZ7I-0005gP-O1 for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 10:59:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeZ7G-00008a-BM for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 10:59:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeZ21-0007Du-Mw for namedroppers-data@psg.com; Fri, 12 May 2006 14:54:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeZ20-0007DK-R9 for namedroppers@ops.ietf.org; Fri, 12 May 2006 14:54:17 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4CEs77M010645; Fri, 12 May 2006 10:54:07 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060512101950.031900e0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 May 2006 10:54:07 -0400 To: Jelte Jansen , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <44644DBB.3080605@NLnetLabs.nl> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <44644DBB.3080605@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 04:56 12/05/2006, Jelte Jansen wrote: > > > >> For the above reasons, I think that we have time to consider the > >> correct course of action. There is no need to rush into more > >> algorithms which require more code on nameservers and resolvers. > > > > Yes, or at least, we need to document a more compelling reason to do > > RSA-SHA-265. > > > >So why is this an issue for RSA/SHA256, and not for >draft-ietf-dnsext-ds-sha256-05.txt, which also makes SHA256 mandatory? The issues here are slightly different. DS digest is the SAME for the lifetime of the DS record. Digest inside a RRSIG is going to be different each time the signature is regenerated for that set, thanks to the different signature lifespan timers. Thus in the case of DS an attacker has much longer to be able to generate a DNSKEY that has a matching DS digest to an existing one. The WG was advised by our Security Area Advisor (Russ Housley) that any use of SHA-1 without HMAC wrapper should be retired. As DS was the most vulnerable the chairs got that effort stared on the spot and RFC4509 should be published any day now. A mitigating fact that RRSIG is not as vulnerable as plain text, against the known SHA1 attacks, is the structured data format of an RRset. Having said that if attack on RRSIG digest, or other structured formats, is valuable enough some smart people will figure out a way to design such an attack. Following up on Hilarie and Rip's messages: One part of the security analysis should be how long signature lifetime can be for the different digest algorithms used as a function of time. This is similar to what is available for lengths of public keys. 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 May 12 13:45:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FebiA-0008QR-7D for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 13:45:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Febi6-0000gN-TM for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 13:45:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Febes-000I2j-3Z for namedroppers-data@psg.com; Fri, 12 May 2006 17:42:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Febeq-000I2P-4B for namedroppers@ops.ietf.org; Fri, 12 May 2006 17:42:32 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B3EAA33C40; Fri, 12 May 2006 18:42:19 +0100 (BST) Message-ID: <4464C959.1070607@algroup.co.uk> Date: Fri, 12 May 2006 18:43:53 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Simon Josefsson CC: Dean Anderson , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= =?ISO-8859-1?Q?_/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <4461FB8A.7070101@algroup.co.uk> <87zmhpapb0.fsf@latte.josefsson.org> In-Reply-To: <87zmhpapb0.fsf@latte.josefsson.org> 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Simon Josefsson wrote: > Ben Laurie writes: > >> Simon Josefsson wrote: >>> Dean Anderson writes: >>> >>>> fault. It is also well to note here that (so far as the Chinese paper goes) >>>> SHA1 has not actually been reversed, but that the computational effort to >>>> perform a reversal requires less effort than previously thought. >>> There is no reversal attack on SHA-1 currently. Wang et al's attack >>> find a collision in 2^69 operations, instead of the expected 2^80. I >>> believe the limit has been improved (2^63 in August 2005). For >>> digital signatures, a collision is all that is required though, you >>> don't need reversal. >> "Required" in what sense? > > "Required" to break the signature scheme. > >> Yes, it allows you to produce two things with the same >> signature. What is the attack on DNSSEC that arises from this? > > Wouldn't such a break violate the property of DNSSEC that after > successful verification of the digital signature, you know the data > you received was the intended published data? If the publisher of the data chooses to publish stuff which could have one of two values for the same signature, then clearly that's what he indended. So, I don't see the problem. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 May 12 14:12:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fec7X-0007TR-2M for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:12:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fec7T-0001sp-Mc for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:12:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fec5e-000KGw-9Q for namedroppers-data@psg.com; Fri, 12 May 2006 18:10:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fec5a-000KGg-Hz for namedroppers@ops.ietf.org; Fri, 12 May 2006 18:10:10 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 3FFE956833; Fri, 12 May 2006 11:10:09 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060512140310.03bffb98@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 12 May 2006 14:09:53 -0400 To: Ben Laurie ,Simon Josefsson From: Mike StJohns Subject: Re: Standardize RSA/SHA256 ? Cc: Dean Anderson ,=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org In-Reply-To: <4464C959.1070607@algroup.co.uk> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <4461FB8A.7070101@algroup.co.uk> <87zmhpapb0.fsf@latte.josefsson.org> <4464C959.1070607@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d At 01:43 PM 5/12/2006, Ben Laurie wrote: > >> Yes, it allows you to produce two things with the same > >> signature. What is the attack on DNSSEC that arises from this? > > > > Wouldn't such a break violate the property of DNSSEC that after > > successful verification of the digital signature, you know the data > > you received was the intended published data? > >If the publisher of the data chooses to publish stuff which could have >one of two values for the same signature, then clearly that's what he >indended. I think this was sarcasm, but its so hard to tell with Ben. So lets assume not: If given an SHA1 summary over DNS data (and it's the summary that is "signed" not the actual data in DNSSEC), I have a method which lets me create a data blob which when summarized will equal that original summary, I can substitute my data blob for the DNS data that was signed and the recipient can't tell the difference. Of course, this assumes that the created data blob can be formatted in a way that it looks like valid DNS data... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 12 14:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FecVj-0003Ia-Cs for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:37:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FecVb-0002ue-T7 for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:37:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FecR9-000LXU-3P for namedroppers-data@psg.com; Fri, 12 May 2006 18:32:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FecR8-000LX5-1Q for namedroppers@ops.ietf.org; Fri, 12 May 2006 18:32:26 +0000 Received: from [66.92.150.17] (HELO [192.168.1.102]) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP-TLS id 13274300; Fri, 12 May 2006 12:31:01 -0600 In-Reply-To: <7.0.1.0.2.20060512140310.03bffb98@nominum.com> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <4461FB8A.7070101@algroup.co.uk> <87zmhpapb0.fsf@latte.josefsson.org> <4464C959.1070607@algroup.co.uk> <7.0.1.0.2.20060512140310.03bffb98@nominum.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Ben Laurie , Simon Josefsson , Dean Anderson , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Mark Feldman Subject: Re: Standardize RSA/SHA256 ? Date: Fri, 12 May 2006 14:32:21 -0400 To: Mike StJohns X-Mailer: Apple Mail (2.749.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da As I understand it, for an attack using collisions that can be generated in current cryptographic hash functions to be effective, the attacker must control the creation of the documents to be signed. In the case of DNSSEC, the attacker would have to create both the ostensibly valid RRSET (with a bunch of binary gobbledygook to make things work ) that is signed and its fraudulent alternative. Since the responsibility for generating and signing an RRSET usually falls to the same individual, breaking the crypto would seem to be unnecessary. I think Ben was referring to this. The Daum/Lucks scenario (http://www.cits.rub.de/MD5Collisions/) works because Postscript is interpreted and the delta between the good and bad documents is used in a conditional to determine which of two views of the document should be presented. Such interpretation is not native to DNS. One might also argue that the set of people likely to look at an RRSET is larger than the set of people likely to look at the Postscript source of a document. Note that it is now possible to create pairs of visually distinct Postscript documents that will produce the same MD5 hash without having to do any computation by simply reusing the core of the Daum/Lucks documents. Mark On May 12, 2006, at 2:09 PM, Mike StJohns wrote: > At 01:43 PM 5/12/2006, Ben Laurie wrote: >> >> Yes, it allows you to produce two things with the same >> >> signature. What is the attack on DNSSEC that arises from this? >> > >> > Wouldn't such a break violate the property of DNSSEC that after >> > successful verification of the digital signature, you know the data >> > you received was the intended published data? >> >> If the publisher of the data chooses to publish stuff which could >> have >> one of two values for the same signature, then clearly that's what he >> indended. > > I think this was sarcasm, but its so hard to tell with Ben. So > lets assume not: > > If given an SHA1 summary over DNS data (and it's the summary that > is "signed" not the actual data in DNSSEC), I have a method which > lets me create a data blob which when summarized will equal that > original summary, I can substitute my data blob for the DNS data > that was signed and the recipient can't tell the difference. > > Of course, this assumes that the created data blob can be formatted > in a way that it looks like valid DNS data... > > > -- > to 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 May 12 14:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fecfi-0007ng-5D for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:47:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fecfh-0003Rh-JT for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 14:47:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FecdF-000MOP-Im for namedroppers-data@psg.com; Fri, 12 May 2006 18:44:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [131.111.8.139] (helo=ppsw-9.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FecdE-000MOC-OU for namedroppers@ops.ietf.org; Fri, 12 May 2006 18:44:56 +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]:54859) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FecdB-0007Fu-Tv (Exim 4.54) (return-path ); Fri, 12 May 2006 19:44:53 +0100 Received: from cet1 by libra.cus.cam.ac.uk with local (Exim 4.61) (envelope-from ) id 1FecdB-0003si-20; Fri, 12 May 2006 19:44:53 +0100 Subject: Re: Standardize RSA/SHA256 ? To: Mike.StJohns@nominum.com (Mike StJohns) Date: Fri, 12 May 2006 19:44:53 +0100 (BST) Cc: ben@algroup.co.uk, namedroppers@ops.ietf.org In-Reply-To: <7.0.1.0.2.20060512140310.03bffb98@nominum.com> from "Mike StJohns" at May 12, 6 02:09:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1805 Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Mike.StJohns@nominum.com (Mike StJohns) writres: > > At 01:43 PM 5/12/2006, Ben Laurie wrote: > > >> Yes, it allows you to produce two things with the same > > >> signature. What is the attack on DNSSEC that arises from this? > > > > > > Wouldn't such a break violate the property of DNSSEC that after > > > successful verification of the digital signature, you know the data > > > you received was the intended published data? > > > >If the publisher of the data chooses to publish stuff which could have > >one of two values for the same signature, then clearly that's what he > >indended. > > I think this was sarcasm, but its so hard to tell with Ben. So lets > assume not: > > If given an SHA1 summary over DNS data (and it's the summary that is > "signed" not the actual data in DNSSEC), I have a method which lets > me create a data blob which when summarized will equal that original > summary, I can substitute my data blob for the DNS data that was > signed and the recipient can't tell the difference. > > Of course, this assumes that the created data blob can be formatted > in a way that it looks like valid DNS data... You are missing the point that "produce two things with the same signature" is not the same thing as "produce a thing with the same signature as a given thing". The existing attacks on MD5 / SHA1 are of the former type: at most they generate two alternative (not too short) bit strings that can be spliced into a given string to produce a pair with the same hash. Of course, the fear is that this will not remain the case. -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 12 19:01:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fegdv-0001tg-SC for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 19:01:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fegdu-0000Z5-7f for dnsext-archive@lists.ietf.org; Fri, 12 May 2006 19:01:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fega8-000Bv9-59 for namedroppers-data@psg.com; Fri, 12 May 2006 22:58:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fega7-000Buw-6I for namedroppers@ops.ietf.org; Fri, 12 May 2006 22:57:59 +0000 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k4CMvUrB007948; Fri, 12 May 2006 15:57:30 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 15:57:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67617.6F2F5468" Subject: Re: Standardize RSA/SHA256 ? Date: Fri, 12 May 2006 15:57:24 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2C5C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standardize RSA/SHA256 ? Thread-Index: AcZ1769NqhLMsGQdS6OvcRjiQbj26gAJ7/dX From: "Hallam-Baker, Phillip" To: "Mike StJohns" , "Ben Laurie" , "Simon Josefsson" Cc: "Dean Anderson" , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= , X-OriginalArrivalTime: 12 May 2006 22:57:25.0251 (UTC) FILETIME=[6F6F0530:01C67617] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. ------_=_NextPart_001_01C67617.6F2F5468 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can imagine instances where update requests are submitted to automatic = verifiers where some sort of exploit is possible. The weakness inherrent in 1024 bit RSA is a much bigger concern. -----Original Message----- From: Mike StJohns [mailto:Mike.StJohns@nominum.com] Sent: Fri May 12 11:12:52 2006 To: Ben Laurie; Simon Josefsson Cc: Dean Anderson; =D3lafur Gu=F0mundsson /DNSEXT co-chair; = namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? At 01:43 PM 5/12/2006, Ben Laurie wrote: > >> Yes, it allows you to produce two things with the same > >> signature. What is the attack on DNSSEC that arises from this? > > > > Wouldn't such a break violate the property of DNSSEC that after > > successful verification of the digital signature, you know the data > > you received was the intended published data? > >If the publisher of the data chooses to publish stuff which could have >one of two values for the same signature, then clearly that's what he >indended. I think this was sarcasm, but its so hard to tell with Ben. So lets=20 assume not: If given an SHA1 summary over DNS data (and it's the summary that is=20 "signed" not the actual data in DNSSEC), I have a method which lets=20 me create a data blob which when summarized will equal that original=20 summary, I can substitute my data blob for the DNS data that was=20 signed and the recipient can't tell the difference. Of course, this assumes that the created data blob can be formatted=20 in a way that it looks like valid DNS data... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C67617.6F2F5468 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Standardize RSA/SHA256 ?

I can imagine instances where update requests are = submitted to automatic verifiers where some sort of exploit is = possible.

The weakness inherrent in 1024 bit RSA is a much bigger concern.



 -----Original Message-----
From:   Mike StJohns [mailto:Mike.StJohns@nominum.com<= /A>]
Sent:   Fri May 12 11:12:52 2006
To:     Ben Laurie; Simon Josefsson
Cc:     Dean Anderson; =D3lafur Gu=F0mundsson = /DNSEXT co-chair; namedroppers@ops.ietf.org
Subject:        Re: Standardize = RSA/SHA256 ?

At 01:43 PM 5/12/2006, Ben Laurie wrote:
> >> Yes, it allows you to produce two things with the same
> >> signature. What is the attack on DNSSEC that arises from = this?
> >
> > Wouldn't such a break violate the property of DNSSEC that = after
> > successful verification of the digital signature, you know the = data
> > you received was the intended published data?
>
>If the publisher of the data chooses to publish stuff which could = have
>one of two values for the same signature, then clearly that's what = he
>indended.

I think this was sarcasm, but its so hard to tell with Ben.  So = lets
assume not:

If given an SHA1 summary over DNS data (and it's the summary that is
"signed" not the actual data in DNSSEC), I have a method which = lets
me create a data blob which when summarized will equal that original
summary, I can substitute my data blob for the DNS data that was
signed and the recipient can't tell the difference.

Of course, this assumes that the created data blob can be formatted
in a way that it looks like valid DNS data...


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

------_=_NextPart_001_01C67617.6F2F5468-- -- to unsubscribe send a message to namedroppers-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 May 13 01:26:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Femdg-0004xM-Jo for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 01:26:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Femde-0003lr-6x for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 01:26:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FemZ3-0005wn-8C for namedroppers-data@psg.com; Sat, 13 May 2006 05:21:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FemZ0-0005wZ-D2 for namedroppers@ops.ietf.org; Sat, 13 May 2006 05:21:16 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4D5L83S015267; Fri, 12 May 2006 22:21:08 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4D5L89u015266; Fri, 12 May 2006 22:21:08 -0700 Date: Fri, 12 May 2006 22:21:08 -0700 Message-Id: <200605130521.k4D5L89u015266@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4509 on Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 A new Request for Comments is now available in online RFC libraries. RFC 4509 Title: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) Author: W. Hardaker Status: Standards Track Date: May 2006 Mailbox: hardaker@tislabs.com Pages: 7 Characters: 14155 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-ds-sha256-05.txt URL: http://www.rfc-editor.org/rfc/rfc4509.txt This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- to unsubscribe send a message to namedroppers-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 May 13 09:05:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FetoQ-0004KT-Fg for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 09:05:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ferne-00047Z-UZ for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 06:56:42 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FerWN-0002Nn-CQ for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 06:38:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FerRo-000LEe-Tw for namedroppers-data@psg.com; Sat, 13 May 2006 10:34:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FerRn-000LEQ-U1 for namedroppers@ops.ietf.org; Sat, 13 May 2006 10:34:08 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 96D0633C3F; Sat, 13 May 2006 11:34:04 +0100 (BST) Message-ID: <4465B67B.2090206@algroup.co.uk> Date: Sat, 13 May 2006 11:35:39 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mike StJohns CC: Simon Josefsson , Dean Anderson , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> <87vesecle7.fsf@latte.josefsson.org> <4461FB8A.7070101@algroup.co.uk> <87zmhpapb0.fsf@latte.josefsson.org> <4464C959.1070607@algroup.co.uk> <7.0.1.0.2.20060512140310.03bffb98@nominum.com> In-Reply-To: <7.0.1.0.2.20060512140310.03bffb98@nominum.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 X-Spam-Score: -1.9 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Mike StJohns wrote: > At 01:43 PM 5/12/2006, Ben Laurie wrote: >> >> Yes, it allows you to produce two things with the same >> >> signature. What is the attack on DNSSEC that arises from this? >> > >> > Wouldn't such a break violate the property of DNSSEC that after >> > successful verification of the digital signature, you know the data >> > you received was the intended published data? >> >> If the publisher of the data chooses to publish stuff which could have >> one of two values for the same signature, then clearly that's what he >> indended. > > I think this was sarcasm, but its so hard to tell with Ben. So lets > assume not: It wasn't. But thanks for the compliment > If given an SHA1 summary over DNS data (and it's the summary that is > "signed" not the actual data in DNSSEC), I have a method which lets me > create a data blob which when summarized will equal that original > summary, I can substitute my data blob for the DNS data that was signed > and the recipient can't tell the difference. Correct, but only if the DNS data that was signed was _also_ chosen by you. So, as I said, clearly you intended for this to be the case. > Of course, this assumes that the created data blob can be formatted in a > way that it looks like valid DNS data... Indeed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 May 13 09:43:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeuPW-0000Ux-5e for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 09:43:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ferne-00047Z-Sc for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 06:56:42 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FerWV-0002Nx-55 for dnsext-archive@lists.ietf.org; Sat, 13 May 2006 06:39:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FerT6-000LKE-U5 for namedroppers-data@psg.com; Sat, 13 May 2006 10:35:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FerT6-000LJy-0v for namedroppers@ops.ietf.org; Sat, 13 May 2006 10:35:28 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 71DF733C1C; Sat, 13 May 2006 11:35:26 +0100 (BST) Message-ID: <4465B6CD.8080005@algroup.co.uk> Date: Sat, 13 May 2006 11:37:01 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Mike StJohns , Simon Josefsson , Dean Anderson , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_?= =?ISO-8859-1?Q?/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: Standardize RSA/SHA256 ? References: <198A730C2044DE4A96749D13E167AD375A2C5C@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2C5C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.2 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hallam-Baker, Phillip wrote: > I can imagine instances where update requests are submitted to automatic > verifiers where some sort of exploit is possible. I can imagine being fabulously wealthy, but it doesn't seem to be getting me anywhere. Specify the attack, don't imagine it. > > The weakness inherrent in 1024 bit RSA is a much bigger concern. > > > > -----Original Message----- > From: Mike StJohns [mailto:Mike.StJohns@nominum.com] > Sent: Fri May 12 11:12:52 2006 > To: Ben Laurie; Simon Josefsson > Cc: Dean Anderson; Ólafur Guðmundsson /DNSEXT co-chair; > namedroppers@ops.ietf.org > Subject: Re: Standardize RSA/SHA256 ? > > At 01:43 PM 5/12/2006, Ben Laurie wrote: >> >> Yes, it allows you to produce two things with the same >> >> signature. What is the attack on DNSSEC that arises from this? >> > >> > Wouldn't such a break violate the property of DNSSEC that after >> > successful verification of the digital signature, you know the data >> > you received was the intended published data? >> >>If the publisher of the data chooses to publish stuff which could have >>one of two values for the same signature, then clearly that's what he >>indended. > > I think this was sarcasm, but its so hard to tell with Ben. So lets > assume not: > > If given an SHA1 summary over DNS data (and it's the summary that is > "signed" not the actual data in DNSSEC), I have a method which lets > me create a data blob which when summarized will equal that original > summary, I can substitute my data blob for the DNS data that was > signed and the recipient can't tell the difference. > > Of course, this assumes that the created data blob can be formatted > in a way that it looks like valid DNS data... > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 yongyuanaini_@163.com Mon May 15 00:23:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUbv-0004Hz-O0 for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 00:23:11 -0400 Received: from [222.169.85.5] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfUbu-00029G-KT for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 00:23:11 -0400 To: From: =?iso-2022-jp?B?eW9uZ3l1YW5haW5pXw==?= Subject: =?iso-2022-jp?B?GyRCPVAycSQkJVElaSVAJSQlOSFaI04jRSNXI08jUCNFI04hWxsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B?75,%*!<%W%s%3%_%e%K%F%#%]!<%?%k(B http://express-cj.biz/deai/ $BLd!K(B jionn@mail.china.com From owner-namedroppers@ops.ietf.org Mon May 15 11:28:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffezn-0004Ms-Lr for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 11:28:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffezk-0008Aj-9N for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 11:28:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfetW-0005rp-IN for namedroppers-data@psg.com; Mon, 15 May 2006 15:22:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfetV-0005rd-C7 for namedroppers@ops.ietf.org; Mon, 15 May 2006 15:22:01 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 May 2006 16:22:00 +0100 X-IronPort-AV: i="4.05,130,1146438000"; d="scan'208"; a="3377635:sNHT30348184" To: namedroppers@ops.ietf.org Subject: SOA records in negative responses MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 15 May 2006 16:22:10 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/15/2006 04:22:10 PM, Serialize complete at 05/15/2006 04:22:10 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, Negative responses may have SOA records included so the cache has an indication for the time it should cache a negative response. With DNSSEC, all negative responses have NSEC records with its own TTL. Therefor, I don't think it is useful to include SOA record and signature(s), saving a little more space, and reducing the amplification vector a bit. I've heard arguments in private discussions that a cache would want the SOA record anyway in order to include it in non-dnssec negative responses to RD=1 requests. However, this is not required, since a resolver could easily return rfc2308 name-error response type 3 or 4 (or nodata response type 3). Is this worth discussing ? Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 15 11:29:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fff0u-0004gJ-Uk for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 11:29:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fff0s-0008E3-Gv for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 11:29:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfeyJ-00068n-Bk for namedroppers-data@psg.com; Mon, 15 May 2006 15:26:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.154.150.108] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfeyF-00068M-Rp for namedroppers@ops.ietf.org; Mon, 15 May 2006 15:26:56 +0000 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 418EF1A3D8; Mon, 15 May 2006 17:26:53 +0200 (CEST) Date: Mon, 15 May 2006 17:26:53 +0200 From: Otmar Lendl To: namedroppers@ops.ietf.org Subject: RR Type allocation for infrastructure ENUM BLR/EBL record Message-ID: <20060515152652.GA10953@bofh.priv.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hello everyone, some of you may have been at the ENUM WG at IETF65 in Dallas. There was some discussion there regarding an interim solution (before moving to a new tree (e.g. ie164.arpa)) where one branches off the User-ENUM tree at a specific point. The storage of the information where and how to branch to this provisional I-ENUM tree has been the source of some rather heated discussion. Last year a proposal (and code) used TXT records at the country-code level to store this information. This has made a lot of people queasy, and visiting people from DNS related WGs remarked that creating a new RR Type isn't that much of a deal any more as RFC3597 is widely supported. See http://www1.ietf.org/mail-archive/web/enum/current/msg04856.html for the WG minutes. So I took up that suggestion, wrote a quick RR Type definition (http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-00.txt) [feedback is welcome on that, too!] and added support for that RR type to the OpenSER SIP proxy. One issue is still unresolved: What RR Type code should I use? I've looked at RFC2929, and went for 65300 for now. This is not optimal. Problems: * I don't think an I-D fulfills "Specification Required as defined in [RFC 2434]", thus I can't get a code in the 32768 - 65279 range. * RFC4020 is way too heavyweight for my purpose. * I can't wait for my draft to become RFC (or even WG document). We're about to release that code now, and as Austria has already launched an Infrastructure ENUM trial last week, we need to agree at least locally to one code ASAP. The whole point of that record is international compatibility, thus a "Private Use." code is definitly counter-productive. * There is no shortage of type-codes. This is not a scarce ressource. We're at less than 70 of 65536 possible codes. That's about 0.1 % utilization. Summary: RFC3597 is very helpful to deploy new ressource record types. The process of selecting a type code is not as easy and quick as I hoped. Recommendations? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 15 12:56:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfgMv-0006Dd-8U for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 12:56:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfgMq-0006xf-Tg for dnsext-archive@lists.ietf.org; Mon, 15 May 2006 12:56:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfgJm-000BRj-BL for namedroppers-data@psg.com; Mon, 15 May 2006 16:53:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FfgJk-000BRU-V4 for namedroppers@ops.ietf.org; Mon, 15 May 2006 16:53:13 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k4FGqMaN012876 for ; Mon, 15 May 2006 12:52:22 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3IaG8y; Mon, 15 May 06 12:51:44 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k4FGnSmI028778; Mon, 15 May 2006 12:49:29 -0400 (EDT) Date: Mon, 15 May 2006 12:51:45 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Otmar Lendl cc: namedroppers@ops.ietf.org, Thomas Narten , Mark Townsley , Margaret Wasserman , iana@iana.org Subject: Re: RR Type allocation for infrastructure ENUM BLR/EBL record In-Reply-To: <20060515152652.GA10953@bofh.priv.at> Message-ID: References: <20060515152652.GA10953@bofh.priv.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 I think you should try to get a real assignment from IANA, and I'm curious as to why you think 4020 is too heavyweight. Aside from that, the most expeditious route may be to publish the draft elsewhere (e.g. a corporate tech report series) and ask IANA to make the allocation based on a document other than an RFC. I did this a few months ago (for the TA typecode), and it worked relatively smoothly -- it was certainly faster than trying to get an RFC published. IANA will almost certainly ask whether your document is 1) readily available and 2) permanent, per the criteria in 2434 and draft-narten-iana-considerations-rfc2434bis-04.txt A couple of more ideas: look again at 4020 and see if you can tolerate it. Or ask the IANA to implement a template procedure for typecodes, so that the template becomes the permanent reference. I think 2929bis is attempting to do that, but I also believe IANA has the option to implement a template system on its own -- I was trying to get that to happen a few months ago but dropped the ball on it. If it would make a big difference to you, I'd be happy to try to get that moving again. I'm also CC'ing the ADs who have overseen DNSEXT in recent years. Thomas Narten, in particular, may have some more ideas for you. -- Sam On Mon, 15 May 2006, Otmar Lendl wrote: > some of you may have been at the ENUM WG at IETF65 in Dallas. ... > So I took up that suggestion, wrote a quick RR Type definition > (http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-00.txt) > [feedback is welcome on that, too!] and added support for that RR > type to the OpenSER SIP proxy. > > One issue is still unresolved: What RR Type code should I use? > > I've looked at RFC2929, and went for 65300 for now. This is not optimal. ... > The process of selecting a type code is not as easy and quick as I hoped. > > Recommendations? -- to unsubscribe send a message to namedroppers-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 May 17 11:10:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNez-0007v8-Hp for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 11:10:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNew-0006Kg-7U for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 11:10:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgNaK-000Iq3-KY for namedroppers-data@psg.com; Wed, 17 May 2006 15:05:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgNaJ-000Ipc-2u for namedroppers@ops.ietf.org; Wed, 17 May 2006 15:05:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B6F2F33C1C for ; Wed, 17 May 2006 16:03:51 +0100 (BST) Message-ID: <446B3B48.10501@algroup.co.uk> Date: Wed, 17 May 2006 08:03:36 -0700 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Proposed NSEC/NSEC3 transition mechanism X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 In order to allow a rollover to NSEC3 from NSEC without going through insecure (although this is not a requirement), I propose the following mechanism. a) Choose a signalling mechanism that the child zone is NSEC3. I favour using the key signing algorithm since this is available to the client no matter how it comes into possession of the key (unlike the DS hash algorithm). b) This signal means "the child zone will use either NSEC or NSEC3". Absence of the signal means "the child zone uses NSEC". c) Call old keys "NSEC keys", new ones "NSEC3 keys". d) Let the time from a zone ceasing to publish a key to the time the world has stopped using that key (i.e. it has expired from all caches) be n. Time T-1: Zone is using NSEC keys. Time T: Zone switches to NSEC3 keys, dropping the NSEC keys. Zone continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys. Time T+n: Zone stops using NSEC, starts using NSEC3. Zone is signed with NSEC3 key only. Between time T and T+n, NSEC-aware resolvers may or my not be able to verify responses, depending on whether they can retrieve the NSEC key or not. If they can retrieve the key, then all works as expected for them. NSEC3-aware resolvers will be able to verify during this time (using NSEC records for negative responses, of course). After T+n, NSEC-aware resolvers no longer understand the zone at all, only NSEC3-aware resolvers do. So, for the whole transition, NSEC3-aware resolvers see a secure zone, and NSEC-aware resolvers either see a secure zone, or see an insecure zone. No-one ever sees a bogus zone. The reverse is similar, but not quite the same. Time T-1: Zone is using NSEC3 keys. Time T: Zone switches to NSEC keys, dropping the NSEC3 keys. Zone switches to NSEC records. Zone is signed with both NSEC and NSEC3 keys. Time T+n: Zone stops signing with NSEC3 keys and signs with NSEC keys only. Cheers, Ben. -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 17 11:43:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOBb-0001Ma-Q2 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 11:43:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOBb-0008OD-9v for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 11:43:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgO7u-000LkZ-MF for namedroppers-data@psg.com; Wed, 17 May 2006 15:39:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgO7s-000LkF-AE for namedroppers@ops.ietf.org; Wed, 17 May 2006 15:39:52 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4HFdavu051967; Wed, 17 May 2006 11:39:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 17 May 2006 11:38:02 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: comments on rollover requirements Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Referring to: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt The document doesn't describe the usage scenarios that we will face - such as close-knit anchor management versus DLV-type anchor management, or complete compromise versus singleton compromise of a zone's key set. Quite frankly, if amazon.com has three keys and one is compromised, I won't be able to discern which one. The news will probably be broadcast on some TV station - what news anchor will be able to spit out which key is the compromised one. Maybe if this were all automated, the difference between complete and singleton compromises is significant, but if there's any manual intervention, I don't thin there is a significant difference. On to comments on section 5... 5.1 Scalability This section ignores scalability from the point of view of the zone operator. The only mention is how many anchors a resolver will configure. No solution ought to be dependent on how many resolvers have the anchor configured. There's not necessarily a relationship between a zone operator and the resolver operators. E.g., the resolvers run at AOL (probably) do not have a special arrangement with .ZA. No business link (like even TLD to registrar) at all. 5.2 IP Encumberance Is this really the second most important point? That's my only comment on this. 5.3 General applicability IOW, don't special case the root zone. What more is there to the requirement? 5.4 Support private networks That sounds like 5.3. All zones ought to be eligible to be anchors. And all zones have parents except the root. (Where would a DS RRSet for the root zone sit?) Is this section supposed to be a stub for split-zone anchoring? Can the support be to "turn off" validation, as in a null DS record? 5.5 Detection of Staleness When you live on top of an unreliable protocol (UDP), you can never "detect" anything reliably. The lack of an obtainable DS RRSet may be the result of a disconnected network and not removal of it. 5.6 Manual operations permitted I think that it should be obvious that an operator can always disable/ignore any automatic attempt to update the configuration of their server. Even the software updating mechanisms for my laptop always ask permission before enacting an upgrade or using upgraded software. 5.7 Planned and unplanned In an automated protocol, there's not much difference, is there? 5.8 Timeliness "Distributed to security-aware resolvers" "timely" highlights the missing portion of 5.1 on scaling. 5.9 High Availability This is needed, and made me wonder why we don't rely more on the CERT RR. 5.10 New RR types 5.11 Support for maintenance This sounds like the functional requirements. 5.12 Recovery from compromise This section is lacking substance. It basically says "if the problem is easy to solve, then it should be solvable." No discussion on whether there is a discernable difference between singleton failures or mass failures. After reading this, in general, what is the interop problem? It is "how does a zone make it's public key (data) known?" On the one hand, I don't want to reinvent the wheel - meaning, why not rely on the CERT RR, a CA infrastructure, and maybe even a MIB for servers? (Yeah, yeah, I know DNS'ers have this thing about MIBs.) On the other hand, how much of this is a detail for implementers? Each server has it's own configuration interface, and trust anchors are just configuration entries? On another hand, do I want to let something as sensitive as trust data be able to be silently updated, especially if it is something I may not understand? (Reading cryptobytes is plaintext hard.) On the other another hand, if I can do this in band, then the trust data passes along a path as safe as the application data (i.e., fates are shared). But the down side is that if the app data can't get through, the trust data can't either. I guess I am still leery of putting this mechanism only in to the port 53 traffic stream. But it has it's advantages. I just don't see this document describing the problem we are setting out to solve. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 17 12:26:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOrH-00030s-O1 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 12:26:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOrH-0001Ci-Mg for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 12:26:47 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgOdT-0006vW-IC for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 12:12:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgOb1-000OEv-HO for namedroppers-data@psg.com; Wed, 17 May 2006 16:09:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgOb0-000OEX-M9 for namedroppers@ops.ietf.org; Wed, 17 May 2006 16:09:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2E43133C3F for ; Wed, 17 May 2006 17:09:55 +0100 (BST) Message-ID: <446B4AD2.6040206@algroup.co.uk> Date: Wed, 17 May 2006 09:09:54 -0700 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: NSEC3 Dynamic Update (proposed) X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 An NSEC3 zone may accept dynamic updates for delegations. If it does, then there are four possible actions it should take, depending on whether the zone is opt-out or not and whether the update is an add or a delete. If the zone is not opt-out and the update is an add then the server MUST generate new NSEC3 records for the newly added owner name and each empty non-terminal it generates (or update the existing NSEC3 records). If the zone is not opt-out and the update is a delete which removes the ownername from the zone, then the server MUST remove all NSEC3 records which contain names made non-existent by the removal of the deleted record, and generate new NSEC3 records for those names still in the zone whose NSEC3 records were removed by that deletion. If the zone is opt-out and the update is an add then, if the update is for any record type other than NS, the server MUST generate new NSEC3 records for the newly added owner name and each empty non-terminal it generates (or update the existing records). For NS records, the server MUST update any existing NSEC3 records, but MUST NOT generate any new NSEC3 records. If the zone is opt-out and the update either removes the ownername or leaves only NS or glue address records at that ownername, then the server MUST remove all NSEC3 records which contain hashes of names made non-existent by the removal of the deleted record's ownername, and generate new NSEC3 records for those opted-in names still in the zone whose NSEC3 records were removed by that deletion. Comments? Cheers, Ben. -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 17 13:47:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQ7J-0004cw-3q for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 13:47:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQ7I-0005R0-N4 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 13:47:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgQ4D-0005hJ-PC for namedroppers-data@psg.com; Wed, 17 May 2006 17:44:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgQ4C-0005h5-O5 for namedroppers@ops.ietf.org; Wed, 17 May 2006 17:44:13 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4HHgt3p052641; Wed, 17 May 2006 13:42:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <446B3B48.10501@algroup.co.uk> References: <446B3B48.10501@algroup.co.uk> Date: Wed, 17 May 2006 13:42:57 -0400 To: Ben Laurie From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a At 8:03 -0700 5/17/06, Ben Laurie wrote: >In order to allow a rollover to NSEC3 from NSEC without going through >insecure (although this is not a requirement), I propose the following >mechanism. Where can I apply to make it a requirement? I'm sure that the advancements made in .SE and at RIPE to date will not want to fall by the wayside. And by the time that NSEC3 is eligible for deployment, more TLDs will be contracturally required to be using DNSSEC. >a) Choose a signalling mechanism that the child zone is NSEC3. I favour >using the key signing algorithm since this is available to the client no >matter how it comes into possession of the key (unlike the DS hash >algorithm). > >b) This signal means "the child zone will use either NSEC or NSEC3". >Absence of the signal means "the child zone uses NSEC". > >c) Call old keys "NSEC keys", new ones "NSEC3 keys". I wish that we do not label keys in this way. It leads us into the same alley where people say "keys expire in DNS." I'd allow NSEC-era keys and NSEC3-era keys. It's the "era" and not the key that changes. >d) Let the time from a zone ceasing to publish a key to the time the >world has stopped using that key (i.e. it has expired from all caches) be n. So, if I have a key derived from the zug-endet-hier algorithm, i.e., algorithm 12, and am using NSEC records today. I want to use the same key and algorithm to start doing NSEC3, I would then add to my DS set a key of the H-zug-endet-hier algorithm number (13). So, now, how do I sign my zone? Do I continue to sign the NSEC records with algorithm 12 or algorithm 13? Both? I assume that I only sign NSEC records with algorithm 13. But then there's that tricky requirement: RFC 4035, 2.2, last paragraph: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). The reason for both records is to wait until enough of the world has adopted new validators. Eventually I stop issuing the NSEC records and then remove the algorithm 12 keys. >Time T-1: Zone is using NSEC keys. > >Time T: Zone switches to NSEC3 keys, dropping the NSEC keys. Zone >continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys. But then how do validators find the keys to validate the previously cached NSEC records? >Time T+n: Zone stops using NSEC, starts using NSEC3. Zone is signed with >NSEC3 key only. > >Between time T and T+n, NSEC-aware resolvers may or my not be able to >verify responses, depending on whether they can retrieve the NSEC key or >not. If they can retrieve the key, then all works as expected for them. >NSEC3-aware resolvers will be able to verify during this time (using >NSEC records for negative responses, of course). After T+n, NSEC-aware >resolvers no longer understand the zone at all, only NSEC3-aware >resolvers do. So, for the whole transition, NSEC3-aware resolvers see a >secure zone, and NSEC-aware resolvers either see a secure zone, or see >an insecure zone. No-one ever sees a bogus zone. > >The reverse is similar, but not quite the same. > >Time T-1: Zone is using NSEC3 keys. > >Time T: Zone switches to NSEC keys, dropping the NSEC3 keys. Zone >switches to NSEC records. Zone is signed with both NSEC and NSEC3 keys. How big can a zone be and have this still be effective? I'd rather see a mechanism in which I can pre-populate the zone with the new records (whether NSEC or NSEC3) and the switch them "on" with the flip of a key. >Time T+n: Zone stops signing with NSEC3 keys and signs with NSEC keys only. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 17 15:11:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRQX-0002C6-FT for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 15:11:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgRQU-0002KK-6E for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 15:11:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgRMr-000C9u-1a for namedroppers-data@psg.com; Wed, 17 May 2006 19:07:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgRMq-000C9e-4M for namedroppers@ops.ietf.org; Wed, 17 May 2006 19:07:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k4HJ6fHU026005 for ; Wed, 17 May 2006 15:06:41 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKTaqXY; Wed, 17 May 06 15:06:36 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k4HIekmI004198; Wed, 17 May 2006 14:40:47 -0400 (EDT) Date: Wed, 17 May 2006 14:43:04 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism In-Reply-To: Message-ID: References: <446B3B48.10501@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Wed, 17 May 2006, Edward Lewis wrote: >> In order to allow a rollover to NSEC3 from NSEC without going through >> insecure (although this is not a requirement),... > > Where can I apply to make it a requirement? By resurrecting and replying to the "NSEC3 requirements question" thread from August 2005. http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01105.html http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01161.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 May 17 17:41:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTlw-0008WK-8C for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 17:41:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTlt-0004hJ-OP for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 17:41:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgTix-000N1T-5u for namedroppers-data@psg.com; Wed, 17 May 2006 21:38:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgTiw-000N1G-4A for namedroppers@ops.ietf.org; Wed, 17 May 2006 21:38:30 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4HLcKPS001566; Wed, 17 May 2006 17:38:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <446B3B48.10501@algroup.co.uk> Date: Wed, 17 May 2006 17:38:17 -0400 To: Sam Weiler From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 At 14:43 -0400 5/17/06, Sam Weiler wrote: >On Wed, 17 May 2006, Edward Lewis wrote: > >>> In order to allow a rollover to NSEC3 from NSEC without going through >>> insecure (although this is not a requirement),... >> >> Where can I apply to make it a requirement? > >By resurrecting and replying to the "NSEC3 requirements question" >thread from August 2005. > >http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01105.html >http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01161.html Okay, here's my rationale for pushing for smooth transition. For the sake of registries that have or will have DNSSEC running prior to the publication of the possible NSEC3 specification, I claim that a means to have a smooth transition from NSEC to NSEC3 and back is essential. Registries are supposed to be run in a reliable, smooth manner. Expecting a registry to drop support for a feature and then pick it up as if it were a flag day to all of its registrants violates this. Flip-flopping is not smooth. It may be true that today there are not many registries that are operating with DNSSEC. But consider that the number may grow before NSEC3 is eligible for operations. Before once again being too optimistic about a time table for NSEC3, recall that in 1999 we thought DNSSEC was ready based on software development only. Granted, I am not giving hard data here, but has anyone trialed NSEC3 in a mixed (NSEC/NSEC3) environment? Has there been sufficient operations testing of interoperable code? This is why I am not so optimistic that NSEC3 can beat contractural requirement for the deployment of DNSSEC. We have long maintained that the DNS is critical to the operation of the Internet. That is why it takes a long time to get any improvements rolled into it. Why expect that this next change would be fast? My requirement for a phase-in/phase-out plan include: 1) No need to stand up a separate DNS constellation (whether this is processes, CPU's, or sites) to fall from one to the other. 2) An incremental means to transfer the needed ancillary data that won't overwhelm other churn in a zone prior to any sort of cut over. I.e., I want the NSEC records prepopulated before going from NSEC3 back to NSEC. 3) The ability to maintain positive DNSSEC validation for answers to queries (with positive answers) during the transition or cut-over. Remember that NSEC/NSEC3 is about just the "oops" cases. 4) Expect that software will be able to provide both an NSEC and an NSEC3 proof of non-existence in the same response packet. 5) "NSEC" and "NSEC3" ought to be thought of as any pair of options (the thought of NSEC5 should be accommodated) for this. 6) The expectation that a zone may want to continue with both NSEC and NSEC3 for an extended period of time. 7) The transition plan needs to consider that DNS data has persistence, i.e., in caches and in other uses. DNS has never been real-time and no matter how hard we try to speed it up, nothing can happen on a strict slice of time. 8) The transition plan has to be simple to follow. Each step will be taken and tested before the next. If there are too many steps, then the process will have to be handed from one shift to the next. It can be long or it can be complex - preferably neither - but it cannot be both. There may be other requriements to add later. Comments on these? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 17 18:03:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU7Q-0001DH-M5 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 18:03:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgU7P-0005uO-CF for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 18:03:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgU4k-000Ocx-N5 for namedroppers-data@psg.com; Wed, 17 May 2006 22:01:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgU4j-000OcP-Ty for namedroppers@ops.ietf.org; Wed, 17 May 2006 22:01:02 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4HM0rmi001657; Wed, 17 May 2006 18:00:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 17 May 2006 18:00:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: some issues with NSEC3, based on the workshop last week Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On a conference call I listed a few concerns I had with NSEC3 based on the workshop held last week. The list here isn't in response to any document, nor is it necessarily complete nor well-supported. For the sake of "entering it into the record" here are things that I still see open ended with regards to NSEC3. (Some of these were in the jabber log, some have been added with a few more minutes of contemplation.) 1) No transition plan yet. (An earlier email went out on this). 2) No coexistence plan (I haven't see anyone test NSEC and NSEC3 in the same tree) or testing. Can NSEC and NSEC3 coexist in the field, or will there be pressure to choose one? Registry operators cannot be easily divided into gTLDs, ccTLD, ENUM registries anymore, usually the same functions will be under the same roof. Ergo, I don't think it's safe to write off NSEC3 as not appropriate for, say, what's in .arpa. 3) The need for debugging tools and hooks. (Tool development is not the IETF's baliwick, but it is a concern to operations.) 4) Why is the number of iterations a parameter? Why can't we just use one number and reply on the degree of freedom provided by the salt. Can there be a limit to the length of the salt to prevent abuse? 5) Is there an opportunity for a malevolent configuration to turn NSEC3 into an attack vector on resolvers, is there a way to make it an amplifier of activity? 6) Is opt-in necessary for NSEC3 or are they different issues? Could NSEC3 be defined without having the complexity of analyzing opt-in for the first go-round? 7) What is the toll on verifiers when the salt (and iterations) are not uniform in the NSEC3 records presented? Is there someway to hide the latency of calculating the hashes needed to start validating of negative answers in the resolver? 8) What will this look like to recursive servers, caching, and negative caching? This is an open issue as we didn't test this in the workshop. WHat does it look like if a zone has just turned on NSEC3, turned it off? See #1. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 17 20:26:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWLd-0003DP-VM for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 20:26:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWLb-00051l-K7 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 20:26:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgWHo-0007BS-GS for namedroppers-data@psg.com; Thu, 18 May 2006 00:22:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgWHn-0007BF-GZ for namedroppers@ops.ietf.org; Thu, 18 May 2006 00:22:39 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 70BB9E60D9 for ; Thu, 18 May 2006 00:22:38 +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.4) with ESMTP id k4I0MSqR040831; Thu, 18 May 2006 10:22:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200605180022.k4I0MSqR040831@drugs.dv.isc.org> To: Ben Laurie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: NSEC3 Dynamic Update (proposed) In-reply-to: Your message of "Wed, 17 May 2006 09:09:54 MST." <446B4AD2.6040206@algroup.co.uk> Date: Thu, 18 May 2006 10:22:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d As background we were also discussing whether a zone should be all opt-out or allow a mixture of opt-out and plain nsec3 records. As far as I can tell there is no real benefit for a mixed zone. You would have to work out which nsec3 spans a given delegation that you wanted to be opted in would has hash into. Also removing the ability to mix and match would simplify update and the initial signing of the zone especially if you didn't also have to track which delegations had to provably exist or not. The rules below give secure delegations probably exist and insecure delegation do not probably exist for opt-out. A zone would be opt-out / plain based on the setting of the opt-out flag in apex's NSEC3 record. I think KISS is a good principle to apply here but it is a trade off. Mark > An NSEC3 zone may accept dynamic updates for delegations. If it does, > then there are four possible actions it should take, depending on > whether the zone is opt-out or not and whether the update is an add or a > delete. > > If the zone is not opt-out and the update is an add then the server MUST > generate new NSEC3 records for the newly added owner name and each empty > non-terminal it generates (or update the existing NSEC3 records). > > If the zone is not opt-out and the update is a delete which removes the > ownername from the zone, then the server MUST remove all NSEC3 records > which contain names made non-existent by the removal of the deleted > record, and generate new NSEC3 records for those names still in the zone > whose NSEC3 records were removed by that deletion. > > If the zone is opt-out and the update is an add then, if the update is > for any record type other than NS, the server MUST generate new NSEC3 > records for the newly added owner name and each empty non-terminal it > generates (or update the existing records). For NS records, the server > MUST update any existing NSEC3 records, but MUST NOT generate any new > NSEC3 records. > > If the zone is opt-out and the update either removes the ownername or > leaves only NS or glue address records at that ownername, then the > server MUST remove all NSEC3 records which contain hashes of names made > non-existent by the removal of the deleted record's ownername, and > generate new NSEC3 records for those opted-in names still in the zone > whose NSEC3 records were removed by that deletion. > > Comments? > > Cheers, > > Ben. > > -- > http://www.links.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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 17 21:06:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWyA-0002Ce-H1 for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 21:06:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWy9-0006aC-0A for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 21:06:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgWwB-0008xO-2Z for namedroppers-data@psg.com; Thu, 18 May 2006 01:04:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgWwA-0008xB-2d for namedroppers@ops.ietf.org; Thu, 18 May 2006 01:04:22 +0000 Received: from [192.168.1.13] ([::ffff:71.246.224.59]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Wed, 17 May 2006 21:04:20 -0400 id 002CC11A.446BC814.000060D4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5870CA58-9F54-4356-A2DB-FD836E5C1B7B@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: some issues with NSEC3, based on the workshop last week Date: Wed, 17 May 2006 21:04:20 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b I'm gonna try and answer the ones that I know the answer to, and ask questions about the issues that you are presenting that I don't understand. On May 17, 2006, at 6:00 PM, Edward Lewis wrote: > On a conference call I listed a few concerns I had with NSEC3 based > on the workshop held last week. The list here isn't in response to > any document, nor is it necessarily complete nor well-supported. > For the sake of "entering it into the record" here are things that > I still see open ended with regards to NSEC3. (Some of these were > in the jabber log, some have been added with a few more minutes of > contemplation.) > > 1) No transition plan yet. (An earlier email went out on this). > > 2) No coexistence plan (I haven't see anyone test NSEC and NSEC3 in > the same tree) or testing. Can NSEC and NSEC3 coexist in the > field, or will there be pressure to choose one? Registry operators > cannot be easily divided into gTLDs, ccTLD, ENUM registries > anymore, usually the same functions will be under the same roof. > Ergo, I don't think it's safe to write off NSEC3 as not appropriate > for, say, what's in .arpa. I don't understand what the difference is between "transition" and "coexistence" here. This is probably just a terminology issue. Are you actually worried that an NSEC3-aware validating resolver wouldn't be able to handle a delegation path with both NSEC and NSEC3? > 3) The need for debugging tools and hooks. (Tool development is > not the IETF's baliwick, but it is a concern to operations.) Since I'm pretty convinced that RFC 4035 DNSSEC doesn't have particularly great debugging tools, I'm not sure what your point is. I don't know what you mean by "hooks". > 4) Why is the number of iterations a parameter? Why can't we just > use one number and reply on the degree of freedom provided by the > salt. Can there be a limit to the length of the salt to prevent > abuse? Salt and iterations solve different problems. Salt is about preventing the use of a pre-computed dictionary. Iterations is about raising the cost of computing that dictionary. Increasing the length of the salt doesn't substantially increase the cost of computing a dictionary (well, unless you make the salt really really really long). There is a limit to the length of the salt: it can be at most 255 octets. > 5) Is there an opportunity for a malevolent configuration to turn > NSEC3 into an attack vector on resolvers, is there a way to make it > an amplifier of activity? The only vector for this that I see is the iterations parameter, and that issue has been addressed in the document. > 6) Is opt-in necessary for NSEC3 or are they different issues? > Could NSEC3 be defined without having the complexity of analyzing > opt-in for the first go-round? They are different issues conceptually, but related implementationally. And as Olaf said (I think), opt-in is the least complicated thing about NSEC3. > 7) What is the toll on verifiers when the salt (and iterations) are > not uniform in the NSEC3 records presented? Is there someway to > hide the latency of calculating the hashes needed to start > validating of negative answers in the resolver? Non-uniform NSEC3 sets in a response is more irritating to code than inefficient to validate. Since I cannot think of a legitimate reason for anything to produce a response with that property, I would suggest that we define such responses as bogus, regardless. Generating a SHA1 hash over a domainname is so much faster than actually verifying a signature, I'm not entirely certain where the latency concern comes from. > 8) What will this look like to recursive servers, caching, and > negative caching? This is an open issue as we didn't test this in > the workshop. WHat does it look like if a zone has just turned on > NSEC3, turned it off? See #1. What does it look like if a zone has just turned on DNSSEC, turned it off? I'm not sure how this is any different. I would guess that we *did* actually test caching in the workshop, even if it was unintentional. We absolutely did test a recursive server in the workshop. -- 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 May 17 23:43:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgZQH-00015X-0A for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 23:43:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgZQE-0007sf-KA for dnsext-archive@lists.ietf.org; Wed, 17 May 2006 23:43:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgZMl-000Ftp-F1 for namedroppers-data@psg.com; Thu, 18 May 2006 03:39:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgZMk-000Ftc-HW for namedroppers@ops.ietf.org; Thu, 18 May 2006 03:39:58 +0000 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k4I3dqQr027740; Wed, 17 May 2006 20:39:52 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 20:39:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Standardize RSA/SHA256 ? Date: Wed, 17 May 2006 20:39:46 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37ABA8B9@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standardize RSA/SHA256 ? Thread-Index: AcZ11RG2XwomNvY+SAmqQBoVkgHQWwD51nGQ From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= , Cc: "Russ Housley" X-OriginalArrivalTime: 18 May 2006 03:39:46.0503 (UTC) FILETIME=[B545AD70:01C67A2C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 I suspect that what Russ actually said was that Working Groups should = plan to transition from SHA-1 because it is unacceptably weak.=20 In the security area the minimum key length for RSA that applications = must support has been 2048 bits for some time. DNSSEC is the only application where a transition from RSA1024 to = RSA2048 creates real operational difficulties. =20 I don't think that weak crypto is a show stopper for deployment of = DNSSEC, it will be a decade or more before breaking a 56 bit key will be = the weakest link in any of the crypto systems in use. But when developers are being told to update their algorithms it seems = to me that you want to make sure that the number of transitions is = minimized rather than the extent of each transition. The task of adding a crypto algorithm to existing code is probably the = most trivial coding change you can imagine. But you still have a full QA = cycle and a full interop cycle and those are never easy or simple. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org=20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of =D3lafur=20 > Gu=F0mundsson /DNSEXT co-chair > Sent: Friday, May 12, 2006 10:54 AM > To: Jelte Jansen; namedroppers@ops.ietf.org > Subject: Re: Standardize RSA/SHA256 ? >=20 > At 04:56 12/05/2006, Jelte Jansen wrote: > > > > > >> For the above reasons, I think that we have time to consider the=20 > > >> correct course of action. There is no need to rush into more=20 > > >> algorithms which require more code on nameservers and resolvers. > > > > > > Yes, or at least, we need to document a more compelling=20 > reason to do=20 > > > RSA-SHA-265. > > > > > > >So why is this an issue for RSA/SHA256, and not for=20 > >draft-ietf-dnsext-ds-sha256-05.txt, which also makes SHA256=20 > mandatory? >=20 > > The issues here are slightly different. >=20 > DS digest is the SAME for the lifetime of the DS record. > Digest inside a RRSIG is going to be different each time the=20 > signature is regenerated for that set, thanks to the=20 > different signature lifespan timers. > Thus in the case of DS an attacker has much longer to be able=20 > to generate a DNSKEY that has a matching DS digest to an existing one. >=20 > The WG was advised by our Security Area Advisor (Russ=20 > Housley) that any use of SHA-1 without HMAC wrapper should be=20 > retired. As DS was the most vulnerable the chairs got that=20 > effort stared on the spot and RFC4509 should be published any day now. >=20 > > A mitigating fact that RRSIG is not as vulnerable as plain=20 > text, against the known SHA1 attacks, is the structured data=20 > format of an RRset. > Having said that if attack on RRSIG digest, or other=20 > structured formats, is valuable enough some smart people will=20 > figure out a way to design such an attack. >=20 > Following up on Hilarie and Rip's messages: > One part of the security analysis should be how long=20 > signature lifetime can be for the different digest algorithms=20 > used as a function of time. > This is similar to what is available for lengths of public keys. >=20 > Olafur=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 18 08:49:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghwa-0007d2-08 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 08:49:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghwZ-0007qJ-F1 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 08:49:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fghs7-000H7H-RN for namedroppers-data@psg.com; Thu, 18 May 2006 12:44:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fghs6-000H72-OX for namedroppers@ops.ietf.org; Thu, 18 May 2006 12:44:55 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4ICies6008079; Thu, 18 May 2006 08:44:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <5870CA58-9F54-4356-A2DB-FD836E5C1B7B@verisignlabs.com> References: <5870CA58-9F54-4356-A2DB-FD836E5C1B7B@verisignlabs.com> Date: Thu, 18 May 2006 08:40:34 -0400 To: David Blacka From: Edward Lewis Subject: Re: some issues with NSEC3, based on the workshop last week Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 At 21:04 -0400 5/17/06, David Blacka wrote: >I don't understand what the difference is between "transition" and >"coexistence" here. This is probably just a terminology issue. Are you >actually worried that an NSEC3-aware validating resolver wouldn't be able to >handle a delegation path with both NSEC and NSEC3? Yes. I have never seen it work. Therefore, I worry. I am also concerned about how an NSEC-era validator will react to a NSEC root, NSEC3 tld, NSEC second-level, a non-signed second-level, etc. Coexistence doesn't just mean "can the new code deal with the old world." Coexistence also covers "can the old code deal with the new world?" >Since I'm pretty convinced that RFC 4035 DNSSEC doesn't have particularly >great debugging tools, I'm not sure what your point is. >I don't know what you mean by "hooks". This is part of "why aren't operators at the IETF." We want tools, which matter more than specs in operations, and the IETF says it doesn't do that. Hooks - protocol features that are present which make maintenance of protocol operations easier. >Salt and iterations solve different problems. Salt is about preventing the >use of a pre-computed dictionary. Iterations is about raising the cost of >computing that dictionary. Increasing the length of the salt doesn't >substantially increase the cost of computing a dictionary (well, unless you >make the salt really really really long). > >There is a limit to the length of the salt: it can be at most 255 octets. Okay, this explains the difference between salt and iterations. No one at the workshop gave that reasoning. That leads me to ask, are iterations an intentional protocol knob that enhances DNS's amplification feature? Are we then trading zone exposure for amplification (and maybe other unknowns)? >The only vector for this that I see is the iterations parameter, and that >issue has been addressed in the document. One of my concerns is a zone that has NSEC3 records with different parameters, forcing a resolver to compute a lot of hashed before finding the needed ones. >They are different issues conceptually, but related implementationally. And >as Olaf said (I think), opt-in is the least complicated thing about NSEC3. Looking at Ben's last message about dynamic update, it seemed that opt-in doubled the cases. Has there been a resolution to the (old?) conflict of wild cards and opt-in? >Non-uniform NSEC3 sets in a response is more irritating to code than >inefficient to validate. Since I cannot think of a legitimate reason for >anything to produce a response with that property, I would suggest that we >define such responses as bogus, regardless. When something is irritating, then only the malevolent will use it. (An attempted twist on a US pro-handgun lobby's slogan: when you outlaw guns, only outlaws will have guns.) What does it mean to label a response as bogus? What about during transitions of NSEC3 parameters? Does this mean we have to count on flash cutovers? >Generating a SHA1 hash over a domainname is so much faster than actually >verifying a signature, I'm not entirely certain where the latency concern >comes from. It takes finite time to calculate a hash. That's latency. "Hiding latency" is something I picked up working in spacecraft ground systems and is something that is a concern in any application where there is a forced wait, like during the lookups in DNS. My question comes from hearing of applications that will issue a scatter shot lookup. Like, if a user types in "tires" to their browser, the browser will as for tires/IN/A, tires/IN/AAAA, tires.tld/IN/A, tires.tld/IN/AAAA, www.tires.tld/IN/A, www.tires.tld/IN/AAAA, with the usual variations on "tld". >What does it look like if a zone has just turned on DNSSEC, turned it off? >I'm not sure how this is any different. To someone that has paid for DNSSEC registration, it looks like they are getting ripped off. >I would guess that we *did* actually test caching in the workshop, even if it >was unintentional. We absolutely did test a recursive server in the workshop. We had the unbound code, which did caching. No other implementation is available. For years we have known that the authority servers are far simpler than the recursive servers, yet we repeatedly go to workshops thinking that code diversity in authority servers is sufficient. This was not new at this workshop, it's been that way for some time. We should learn not rest on such laurels. We also know that issues in recursion sometimes take quite a while to appear. Race conditions as TTLs expire take time to appear. I have never seen a key roll scenarion work completely without an outage. Usually this problem creeps up at the end of a multi-day workshop/tutorial and we've run out of gas for the debugging. The point is that we did have recursive code running. But it was far from tested to satisfaction. And not to lay the blame on the code, there were bugs (fixed) in the authority servers (how many NSD's and BIND's code cuts were redist'd in the first two days) and there were configurations bugs (like forgetting to reset NSD's runtime parameters on a restart.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 18 09:07:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiDl-0005OL-UP for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 09:07:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgiDi-0000Au-BI for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 09:07:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgiAo-000IfV-Nj for namedroppers-data@psg.com; Thu, 18 May 2006 13:04:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.223] (helo=mail3.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgiAn-000IfG-Bt for namedroppers@ops.ietf.org; Thu, 18 May 2006 13:04:13 +0000 Received: by mail3.sea.safepages.com (Postfix, from userid 1012) id 5552EB7E60; Thu, 18 May 2006 13:04:12 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.101]) by mail3.sea.safepages.com (Postfix) with ESMTP id 45556B7F5A; Thu, 18 May 2006 13:04:08 +0000 (GMT) Message-ID: <446C70BD.3020905@connotech.com> Date: Thu, 18 May 2006 09:03: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: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: comments on rollover requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Thanks Mr. Lewis for your observations. I somehow share your overall concerns, so I don't repeat. I give some specific feedback below. Edward Lewis wrote: > Referring to: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt > > > The document doesn't describe the usage scenarios that we will face - > such as close-knit anchor management versus DLV-type anchor management, > or complete compromise versus singleton compromise of a zone's key set. DLV versus TAK rollover is a resolver issue. Currently only relevant to BIND resolver source code, if at all. Raising DLV interoperability with TAK rollover to a full-blown requirement is a step I would rather not see. "complete compromise versus singleton compromise of a zone's key set" (I assume this refers to the KSK subset of the zone's key set, for the root or an island of trust, since other cases are not related to TAK management) You seem to adopt the security model of e.g. draft-ietf-dnsext-trustupdate-timers-02.txt, while a more abstract notion of "catastrophic failure mode" is more encompassing as a framework for formulating requirements. No scheme is devoid of a catastrophic failure mode, the idea is to select a scheme where the catastrophic failure can be made less likely. > Quite frankly, if amazon.com has three keys and one is compromised, I > won't be able to discern which one. The news will probably be broadcast > on some TV station - what news anchor will be able to spit out which key > is the compromised one. Maybe if this were all automated, the > difference between complete and singleton compromises is significant, > but if there's any manual intervention, I don't thin there is a > significant difference. The DNSEXT WG is chartered to work on an automated trust anchor key rollover solution, and the "complete compromise" (i.e. "catastrophic failure") is indeed significant as a circumstance where the automation does not work. > On to comments on section 5... > > [[...]] > > 5.7 Planned and unplanned > > In an automated protocol, there's not much difference, is there? > The DNS heartbeat is paced by TTL values. The DNSSEC notions of inception and expiration times may be used to pace the planned automated TAK rollover (e.g. in draft-moreau-dnsext-sdda-rr-02.txt). An emergency/unplanned rollover may be forced by manually "flushing the cache" in a DNS resolver, for the relevant section of the DNS state information (i.e. relevant to TAK management). This would be a suggested system management action following a specialized press report that some TAK has been compromised. In other words, scheduled/planned rollover should perform the same security sanitization as expecteded from an emergency/unplanned rollover -- the difference is the possible manual trigger for the emergency case, avoiding the latency from the DNS resolver polling heartbeat. > [[...]] 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 May 18 10:00:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgj3U-0006f1-L5 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 10:00:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgj3U-00031k-J5 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 10:00:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgj3Q-0003Iz-I5 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 10:00:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgj0E-000Mss-BU for namedroppers-data@psg.com; Thu, 18 May 2006 13:57:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgj0D-000Msd-Kp for namedroppers@ops.ietf.org; Thu, 18 May 2006 13:57:21 +0000 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k4IDvJQt013625; Thu, 18 May 2006 06:57:19 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 06:57:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed NSEC/NSEC3 transition mechanism Date: Thu, 18 May 2006 06:57:17 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37ABA8D0@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed NSEC/NSEC3 transition mechanism Thread-Index: AcZ5+uRnsT2SnjowSsSlEegbLNbraQAhcyXQ From: "Hallam-Baker, Phillip" To: "Edward Lewis" , "Sam Weiler" Cc: X-OriginalArrivalTime: 18 May 2006 13:57:13.0749 (UTC) FILETIME=[F726CC50:01C67A82] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 =20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward Lewis > For the sake of registries that have or will have DNSSEC=20 > running prior to the publication of the possible NSEC3=20 > specification, I claim that a means to have a smooth=20 > transition from NSEC to NSEC3 and back is essential. I do not see such a need.=20 In the first place one of the the original premises for NSEC3 was that a = walkable zone would be in breach of EU privacy regulations the only = transitions required would be between NSEC3 and a successor or NSEC3 and = no DNSSEC. Secondly as a security specialist I think that Ed vastly over states the = degree of dependency that is likely to be created within the scope of = the early deployment. I think DNSSEC is important as a security specialist but it is going to = take a huge effort to convince the world of that. Premature reliance has = never been a problem in previous deployments. It may be important to create such documents for specific deployment = instances but there is a vast difference between operational documents = relating to a specific deployment and a standards document. I see = neither use nor justification for developing a document that describes a = transition between every possible configuration of two schemes in the = absence of any stated interest in making such a transition. -- to unsubscribe send a message to namedroppers-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 May 18 10:42:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjhz-000659-EN for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 10:42:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgjhx-00063T-UM for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 10:42:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgjdc-0000Kh-Lj for namedroppers-data@psg.com; Thu, 18 May 2006 14:38:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgjdb-0000KU-K8 for namedroppers@ops.ietf.org; Thu, 18 May 2006 14:38:04 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4IEbpbm008647; Thu, 18 May 2006 10:37:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37ABA8D0@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37ABA8D0@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Thu, 18 May 2006 10:37:52 -0400 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: RE: Proposed NSEC/NSEC3 transition mechanism Cc: "Edward Lewis" , "Sam Weiler" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 At 6:57 -0700 5/18/06, Hallam-Baker, Phillip wrote: >In the first place one of the the original premises for NSEC3 was that a >walkable zone would be in breach of EU privacy regulations the only >transitions required would be between NSEC3 and a successor or NSEC3 and no >DNSSEC. This may be the case, but "original premises" often become historical footnotes. (Recall my presentation about DNS to the MARID interim meeting where I was told to stop telling the amassed audience why things in DNS are the way they are - blaming it on original premises.) Looking at what NSEC3 offers, it goes beyond EU privacy regulations. If it were just that, why hack the DNS when whois is the real culprit (in the disclosure of identifying information)? (Yes, I know that NSEC's point a miner to the data in whois, but the data *is* in whois.) The Brazilian registry is (alleged come to think of it) also interested in NSEC3. One of the points made by Nominet engineers is that they are concerned by the traffic load zone walking attempts would engender. I mention this because I think it would be foolhardy to restrict an analysis of NSEC3 to the context of the original premises. I go further to say that NSEC3 may wind up being used in ENUM and the like zones. >Secondly as a security specialist I think that Ed vastly over states the >degree of dependency that is likely to be created within the scope of the >early deployment. Would you clarify what you mean by this comment? I hope the "security specialist" doesn't apply to me, nor an I sure what you mean by "vastly over stat[ing]...dependency." >I think DNSSEC is important as a security specialist but it is going to take a >huge effort to convince the world of that. Premature reliance has never been a >problem in previous deployments. I am at a loss to respond to that too. I would think that premature reliance has been a real pain in many arenas, I recall a lament that one vendor shipped DHCP code based on a draft, forcing a WG into sticking with a bad solution in 1999. Not to demean the involved parties then, but it's the most descriptive example of premature reliance I know of. >It may be important to create such documents for specific deployment instances >but there is a vast difference between operational documents relating to a >specific deployment and a standards document. I see neither use nor >justification for developing a document that describes a transition between >every possible configuration of two schemes in the absence of any stated >interest in making such a transition. Since the SiteFinder incident and fallout is that IETF protocols do not stand on their own. IETF defined protocols assume a carefully crafted operational environment. Although the introduction of the wild card into COM and NET back then fell well within DNS protocol design and specification, there was a huge operational backlash, with misaddressed mail suddenly getting delivered as if it were corrent, spam blockers failing to find names as not in DNS, etc. An example of not considering operstions - RFC 2065 and 2535. These two earlier attempts at DNSSEC had no and then just some operations input. RFC 403[345] are said to be improvements based on operational input. My raising this issue now could be seen as a means to delay NSEC3, in the sense that asking for "one more thing to be defined." The "victims" of this are zones that have reasons to not deploy NSEC, but not discussing this will cause problems for zones that are under pressure to deploy NSEC now and in the coming time - and then may be told to transition later. Because I think such considerations are distasteful, I've held back from making comments, but I'm also tired of seeing history repeat itself. Meaning - we need to consider operations. Might as well be now. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 18 11:07:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgk6F-0007CT-Fn for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 11:07:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgk6F-0007LU-ER for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 11:07:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgjzj-0003wR-S4 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 11:00:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgjxI-0001ym-QZ for namedroppers-data@psg.com; Thu, 18 May 2006 14:58:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgjxH-0001yW-Vt for namedroppers@ops.ietf.org; Thu, 18 May 2006 14:58:24 +0000 Received: from [192.168.0.102] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 70A47C2DA3; Thu, 18 May 2006 15:58:22 +0100 (BST) Date: Thu, 18 May 2006 15:58:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , "Hallam-Baker, Phillip" Cc: Edward Lewis , Sam Weiler , namedroppers@ops.ietf.org, Alex Bligh Subject: RE: Proposed NSEC/NSEC3 transition mechanism Message-ID: In-Reply-To: References: <198A730C2044DE4A96749D13E167AD37ABA8D0@MOU1WNEXMB04.vcorp.ad.vr sn.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 X-Spam-Score: -0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --On 18 May 2006 10:37 -0400 Edward Lewis wrote: >> In the first place one of the the original premises for NSEC3 was that a >> walkable zone would be in breach of EU privacy regulations the only >> transitions required would be between NSEC3 and a successor or NSEC3 and >> no DNSSEC. > > This may be the case, but "original premises" often become historical > footnotes. (Recall my presentation about DNS to the MARID interim > meeting where I was told to stop telling the amassed audience why things > in DNS are the way they are - blaming it on original premises.) > > Looking at what NSEC3 offers, it goes beyond EU privacy regulations. I agree with Ed here in as much as I think having a path between NSEC2 and NSEC3 (and possibly vice-versa) that does not at any time make the zone less secure/functional than the least secure of the start point and end point of the transition is probably a requirement. In practice I think that boils down to a transition between NSEC2 and NSEC3 (and possibly vice-versa) not making the zone return bogus or insecure results where it would not have done so as a "pure" NSEC2 or NSEC3 zone ab initio (obviously taking an NSEC2 zone and making it NSEC3 only is at some point going to cause NSEC2 only resolvers to fail). Similarly between no DNSSEC and NSEC3. But I'm not sure the requirement goes a long way beyond that, does it? I also agree that if we are looking for wide adoption, our security yardstick should be the protocol itself, not merely looking at the likely use-cases of those who advanced it. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 18 12:26:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglL1-0004hw-RK for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:26:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglL1-00049B-Px for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:26:59 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FglL0-0004ym-59 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:26:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FglIz-0007HB-Bc for namedroppers-data@psg.com; Thu, 18 May 2006 16:24:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FglIy-0007H0-JN for namedroppers@ops.ietf.org; Thu, 18 May 2006 16:24:52 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4IGOamO009343; Thu, 18 May 2006 12:24:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 18 May 2006 12:24:31 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -1.5 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 At 18:05 +0200 5/18/06, Roy Arends wrote: >If what you want is both NSEC and NSEC3 records being served for a long >period of time from a single zone, I'd have to dissappoint you: it is >silly, since serving NSEC defeats the whole purpose of serving NSEC3, >right ? I used to agree, but not post-workshop and not trying to work this into an operational scenario. If the goal is to conform with a requirement to use NSEC3 and still support NSEC-era validators, there is a reason to return both. Being able to do both affords much more flexibility in transition, affords greater stability. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 18 12:28:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglMv-000510-LE for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:28:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglMs-0004GZ-7L for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:28:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FglJY-0007Kl-0C for namedroppers-data@psg.com; Thu, 18 May 2006 16:25:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FglJW-0007KK-Bp for namedroppers@ops.ietf.org; Thu, 18 May 2006 16:25:26 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C9AAC33C40; Thu, 18 May 2006 17:25:23 +0100 (BST) Message-ID: <446C9FF2.6050204@algroup.co.uk> Date: Thu, 18 May 2006 09:25:22 -0700 From: Ben Laurie User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism References: <446B3B48.10501@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Edward Lewis wrote: > At 8:03 -0700 5/17/06, Ben Laurie wrote: >> In order to allow a rollover to NSEC3 from NSEC without going through >> insecure (although this is not a requirement), I propose the following >> mechanism. > > Where can I apply to make it a requirement? I'm sure that the > advancements made in .SE and at RIPE to date will not want to fall by > the wayside. And by the time that NSEC3 is eligible for deployment, > more TLDs will be contracturally required to be using DNSSEC. > >> a) Choose a signalling mechanism that the child zone is NSEC3. I favour >> using the key signing algorithm since this is available to the client no >> matter how it comes into possession of the key (unlike the DS hash >> algorithm). >> >> b) This signal means "the child zone will use either NSEC or NSEC3". >> Absence of the signal means "the child zone uses NSEC". >> >> c) Call old keys "NSEC keys", new ones "NSEC3 keys". > > I wish that we do not label keys in this way. It leads us into the same > alley where people say "keys expire in DNS." I'd allow NSEC-era keys > and NSEC3-era keys. It's the "era" and not the key that changes. Sure thing. > >> d) Let the time from a zone ceasing to publish a key to the time the >> world has stopped using that key (i.e. it has expired from all caches) >> be n. > > So, if I have a key derived from the zug-endet-hier algorithm, i.e., > algorithm 12, and am using NSEC records today. I want to use the same > key and algorithm to start doing NSEC3, I would then add to my DS set a > key of the H-zug-endet-hier algorithm number (13). Nope, you'd replace the key, not add one. > So, now, how do I sign my zone? Do I continue to sign the NSEC records > with algorithm 12 or algorithm 13? Both? I assume that I only sign > NSEC records with algorithm 13. But then there's that tricky requirement: > > RFC 4035, 2.2, last paragraph: > > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset > itself MUST be signed by each algorithm appearing in the DS RRset > located at the delegating parent (if any). > > The reason for both records is to wait until enough of the world has > adopted new validators. Eventually I stop issuing the NSEC records and > then remove the algorithm 12 keys. > >> Time T-1: Zone is using NSEC keys. >> >> Time T: Zone switches to NSEC3 keys, dropping the NSEC keys. Zone >> continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys. > > But then how do validators find the keys to validate the previously > cached NSEC records? They don't. > >> Time T+n: Zone stops using NSEC, starts using NSEC3. Zone is signed with >> NSEC3 key only. >> >> Between time T and T+n, NSEC-aware resolvers may or my not be able to >> verify responses, depending on whether they can retrieve the NSEC key or >> not. If they can retrieve the key, then all works as expected for them. >> NSEC3-aware resolvers will be able to verify during this time (using >> NSEC records for negative responses, of course). After T+n, NSEC-aware >> resolvers no longer understand the zone at all, only NSEC3-aware >> resolvers do. So, for the whole transition, NSEC3-aware resolvers see a >> secure zone, and NSEC-aware resolvers either see a secure zone, or see >> an insecure zone. No-one ever sees a bogus zone. >> >> The reverse is similar, but not quite the same. >> >> Time T-1: Zone is using NSEC3 keys. >> >> Time T: Zone switches to NSEC keys, dropping the NSEC3 keys. Zone >> switches to NSEC records. Zone is signed with both NSEC and NSEC3 keys. > > How big can a zone be and have this still be effective? > > I'd rather see a mechanism in which I can pre-populate the zone with the > new records (whether NSEC or NSEC3) and the switch them "on" with the > flip of a key. This is an implementation issue, surely? > >> Time T+n: Zone stops signing with NSEC3 keys and signs with NSEC keys >> only. > -- http://www.links.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 May 18 12:52:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fglk9-0006xf-J9 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:52:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fglk9-0005W7-Hn for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:52:57 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgljN-0005BA-W0 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:52:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fglg1-0008wK-IZ for namedroppers-data@psg.com; Thu, 18 May 2006 16:48:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fglg0-0008w2-Dm; Thu, 18 May 2006 16:48:40 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 May 2006 17:48:38 +0100 X-IronPort-AV: i="4.05,142,1146438000"; d="scan'208"; a="3822750:sNHT32437472" In-Reply-To: To: Edward Lewis Cc: Edward Lewis , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Thu, 18 May 2006 18:48:45 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/18/2006 05:48:44 PM, Serialize complete at 05/18/2006 05:48:44 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 owner-namedroppers@ops.ietf.org wrote on 05/18/2006 06:24:31 PM: > At 18:05 +0200 5/18/06, Roy Arends wrote: > > >If what you want is both NSEC and NSEC3 records being served for a long > >period of time from a single zone, I'd have to dissappoint you: it is > >silly, since serving NSEC defeats the whole purpose of serving NSEC3, > >right ? > > I used to agree, but not post-workshop and not trying to work this > into an operational scenario. If the goal is to conform with a > requirement to use NSEC3 and still support NSEC-era validators, there > is a reason to return both. Being able to do both affords much more > flexibility in transition, affords greater stability. If we didn't happen to already pass this station a long time ago, I'd make this an explicit NON-requirement. Domain-holders have to choose between serving to NSEC-only resolvers or NSEC/NSEC3 capable resolvers, where the tradeoff is between deployed base and zone-enumeration. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 18 13:11:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgm1k-00052t-9B for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 13:11:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglGm-0003yT-LH for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:22:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgl3u-0004l9-Ee for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:09:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgl0M-00062K-DM for namedroppers-data@psg.com; Thu, 18 May 2006 16:05:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgl0K-00061f-KC; Thu, 18 May 2006 16:05:36 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 May 2006 17:05:34 +0100 X-IronPort-AV: i="4.05,142,1146438000"; d="scan'208"; a="3417358:sNHT35555236" In-Reply-To: To: Edward Lewis Cc: Ben Laurie , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Thu, 18 May 2006 18:05:41 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/18/2006 05:05:41 PM, Serialize complete at 05/18/2006 05:05:41 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Edward Lewis wrote on 05/17/2006 07:42:57 PM: > At 8:03 -0700 5/17/06, Ben Laurie wrote: > >In order to allow a rollover to NSEC3 from NSEC without going through > >insecure (although this is not a requirement), I propose the following > >mechanism. > > >a) Choose a signalling mechanism that the child zone is NSEC3. I favour > >using the key signing algorithm since this is available to the client no > >matter how it comes into possession of the key (unlike the DS hash > >algorithm). > > > >b) This signal means "the child zone will use either NSEC or NSEC3". > >Absence of the signal means "the child zone uses NSEC". > > > >c) Call old keys "NSEC keys", new ones "NSEC3 keys". > > I wish that we do not label keys in this way. It leads us into the > same alley where people say "keys expire in DNS." I'd allow NSEC-era > keys and NSEC3-era keys. It's the "era" and not the key that changes. Sure. > >d) Let the time from a zone ceasing to publish a key to the time the > >world has stopped using that key (i.e. it has expired from all caches) be n. > > So, if I have a key derived from the zug-endet-hier algorithm, i.e., > algorithm 12, and am using NSEC records today. I want to use the > same key and algorithm to start doing NSEC3, I would then add to my > DS set a key of the H-zug-endet-hier algorithm number (13). > > So, now, how do I sign my zone? Do I continue to sign the NSEC > records with algorithm 12 or algorithm 13? Both? I assume that I > only sign NSEC records with algorithm 13. But then there's that > tricky requirement: > > RFC 4035, 2.2, last paragraph: > > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset > itself MUST be signed by each algorithm appearing in the DS RRset > located at the delegating parent (if any). > > The reason for both records is to wait until enough of the world has > adopted new validators. Eventually I stop issuing the NSEC records > and then remove the algorithm 12 keys. This is a key rollover, the same kind of rollover you have to have in 403[345] ? Nothing new here. > >Time T-1: Zone is using NSEC keys. Zone is using zug-endet-hier keys. > >Time T: Zone switches to NSEC3 keys, dropping the NSEC keys. Zone > >continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys. Time T: Zone switches to h-zug-endet-hier keys, dropping the zug-endet-hier keys. Zone continues to use NSEC. Zone is signed with both zug-endet-hier keys and h-zug-endet-hier keys. > But then how do validators find the keys to validate the previously > cached NSEC records? This is still a key-rollover. Nothing new here. > >Time T+n: Zone stops using NSEC, starts using NSEC3. Zone is signed with > >NSEC3 key only. > > > >Between time T and T+n, NSEC-aware resolvers may or my not be able to > >verify responses, depending on whether they can retrieve the NSEC key or > >not. If they can retrieve the key, then all works as expected for them. > >NSEC3-aware resolvers will be able to verify during this time (using > >NSEC records for negative responses, of course). After T+n, NSEC-aware > >resolvers no longer understand the zone at all, only NSEC3-aware > >resolvers do. So, for the whole transition, NSEC3-aware resolvers see a > >secure zone, and NSEC-aware resolvers either see a secure zone, or see > >an insecure zone. No-one ever sees a bogus zone. > > >The reverse is similar, but not quite the same. > > > >Time T-1: Zone is using NSEC3 keys. > > > >Time T: Zone switches to NSEC keys, dropping the NSEC3 keys. Zone > >switches to NSEC records. Zone is signed with both NSEC and NSEC3 keys. > > How big can a zone be and have this still be effective? It is a zone with 2 signatures on every record, as is the case with any other key roll. > I'd rather see a mechanism in which I can pre-populate the zone with > the new records (whether NSEC or NSEC3) and the switch them "on" with > the flip of a key. Which is _exactly_ what happens here. We switch from DNSSEC to DNS for nsec-resolvers by the flip of a key. Meanwhile nsec3 resolver never treats the zone as not secured. The key flip you want happens at point T. I kinda like this 2-step approach. Simple and effective. It doesn't require the authoritative nsec3-server to have additional complexity to serve both records in a response. It also does not add any complexity to current resolvers or new nsec3-resolvers. If what you want is both NSEC and NSEC3 records being served for a long period of time from a single zone, I'd have to dissappoint you: it is silly, since serving NSEC defeats the whole purpose of serving NSEC3, right ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 18 14:26:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnCT-0007eO-8E for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 14:26:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnCS-00028q-OD for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 14:26:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgn9N-000EOd-Ue for namedroppers-data@psg.com; Thu, 18 May 2006 18:23:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgn9M-000EOM-PT for namedroppers@ops.ietf.org; Thu, 18 May 2006 18:23:04 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 18 May 2006 14:23:03 -0400 id 002D002A.446CBB87.00000372 In-Reply-To: References: <5870CA58-9F54-4356-A2DB-FD836E5C1B7B@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A688651-3ADB-4197-8977-A809CE11858D@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: some issues with NSEC3, based on the workshop last week Date: Thu, 18 May 2006 14:23:02 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 On May 18, 2006, at 8:40 AM, Edward Lewis wrote: > At 21:04 -0400 5/17/06, David Blacka wrote: > >> I don't understand what the difference is between "transition" and >> "coexistence" here. This is probably just a terminology issue. >> Are you >> actually worried that an NSEC3-aware validating resolver wouldn't >> be able to >> handle a delegation path with both NSEC and NSEC3? > > Yes. I have never seen it work. Therefore, I worry. Well, I feel certain that it will be tested. However, if *you* need to see it work, then I would suggest that the best way to see it is to test it yourself. I will state that this case does not worry me, personally. Keep in mind that if the resolver is following a secure delegation path, then the returned referrals look the same between NSEC3 and NSEC signed zones. If the path is insecure, then it is sufficient to know that the validator will correctly determine it in both the NSEC and NSEC3 cases. > I am also concerned about how an NSEC-era validator will react to a > NSEC root, NSEC3 tld, NSEC second-level, a non-signed second-level, > etc. Coexistence doesn't just mean "can the new code deal with the > old world." Coexistence also covers "can the old code deal with the > new world?" Protocol-wise, I see this as an orthogonal issue. The "transition" (or coexistence) technique is just as likely to work for NSEC8 as NSEC3. We will get to testing this as well. >> Since I'm pretty convinced that RFC 4035 DNSSEC doesn't have >> particularly >> great debugging tools, I'm not sure what your point is. >> I don't know what you mean by "hooks". > > This is part of "why aren't operators at the IETF." We want tools, > which matter more than specs in operations, and the IETF says it > doesn't do that. I still don't get the point. Are you just whining, or is there something you want the working group to do? > Hooks - protocol features that are present which make maintenance > of protocol operations easier. I still don't know what you are talking about. >> Salt and iterations solve different problems. Salt is about >> preventing the >> use of a pre-computed dictionary. Iterations is about raising the >> cost of >> computing that dictionary. Increasing the length of the salt doesn't >> substantially increase the cost of computing a dictionary (well, >> unless you >> make the salt really really really long). >> >> There is a limit to the length of the salt: it can be at most 255 >> octets. > > Okay, this explains the difference between salt and iterations. No > one at the workshop gave that reasoning. > > That leads me to ask, are iterations an intentional protocol knob > that enhances DNS's amplification feature? Are we then trading > zone exposure for amplification (and maybe other unknowns)? Ed, this whole issue was discussed at length on namedroppers. It resulted in section 8.1 of the current nsec3 document. >> They are different issues conceptually, but related >> implementationally. And >> as Olaf said (I think), opt-in is the least complicated thing >> about NSEC3. > > Looking at Ben's last message about dynamic update, it seemed that > opt-in doubled the cases. True, but it all so straightforward. > Has there been a resolution to the (old?) conflict of wild cards > and opt-in? What conflict? >> Non-uniform NSEC3 sets in a response is more irritating to code than >> inefficient to validate. Since I cannot think of a legitimate >> reason for >> anything to produce a response with that property, I would suggest >> that we >> define such responses as bogus, regardless. > > When something is irritating, then only the malevolent will use it. > (An attempted twist on a US pro-handgun lobby's slogan: when you > outlaw guns, only outlaws will have guns.) > > What does it mean to label a response as bogus? Define as bogus. Treat as bogus. Not support. Fail validation when seeing such a response. Make illegal. You tell me what phrase works for you. > What about during transitions of NSEC3 parameters? Does this mean > we have to count on flash cutovers? You mean, does an authoritative server have to answer responses using one set of NSEC3 parameters one moment, then answer using a different set the next? Yes. Does it have to suddenly replace all NSEC3 records with a different set of NSEC3 records? No. >> Generating a SHA1 hash over a domainname is so much faster than >> actually >> verifying a signature, I'm not entirely certain where the latency >> concern >> comes from. > > It takes finite time to calculate a hash. That's latency. I wasn't denying the existence of latency, I was questioning the concern. Is there a way to hide the latency caused by verifying a signature? There is more work for the validator to do when validating a negative response with NSEC3 records, but the increased amount of work is less than the time it would take to verify an additional signature. So I have a very hard time getting excited about it. >> What does it look like if a zone has just turned on DNSSEC, turned >> it off? >> I'm not sure how this is any different. > > To someone that has paid for DNSSEC registration, it looks like > they are getting ripped off. I think the point of your original question has gotten lost. I was trying to ask another question in the hope of focusing your problem statement, but I totally failed. Your original concern was a fairly vague worry that something might go wrong when a zone turns on NSEC3 and then turns it off. My problem with responding to your vague worry is that it is too unspecific for me to get a handle on it. But in general, I'm having a hard time seeing how switching NSEC3 on and off is substantially different than any other zone change. Resolvers work with each response individually. -- 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 Thu May 18 14:41:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnRe-0005DJ-FA for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 14:41:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglGm-0003yT-Be for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:22:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgl4J-0004lT-2w for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 12:09:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgl2Y-00069H-78 for namedroppers-data@psg.com; Thu, 18 May 2006 16:07:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgl2X-000695-Hq for namedroppers@ops.ietf.org; Thu, 18 May 2006 16:07:53 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k4IG7lJ7020739; Thu, 18 May 2006 09:07:48 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 09:07:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed NSEC/NSEC3 transition mechanism Date: Thu, 18 May 2006 09:07:46 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37ABA8F7@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed NSEC/NSEC3 transition mechanism Thread-Index: AcZ6iMQ8MqJmZ+N5SamdrraQk/IxYgABS1Jg From: "Hallam-Baker, Phillip" To: "Edward Lewis" Cc: "Sam Weiler" , X-OriginalArrivalTime: 18 May 2006 16:07:41.0608 (UTC) FILETIME=[30EB4A80:01C67A95] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 > This may be the case, but "original premises" often become=20 > historical footnotes. (Recall my presentation about DNS to=20 > the MARID interim meeting where I was told to stop telling=20 > the amassed audience why things in DNS are the way they are -=20 > blaming it on original premises.) What people were complained about was your refusal to listen to anyone. = Assuming you know what someone is going to say and then talking over = them as they attempt to say it is not a particularly efficient form of = communication even when you know what they are going to say which you = did not. I had to personally ask you to stop interrupting six times before I = managed to say my first sentence. I am not sure how you would know what I intended to say in the meeting = since I am pretty sure that I forgot half of it while you were heckling. = It is one thing to interrupt someone who has been talking for five = minutes with a well placed point of information, quite a different thing = to do as you did and drown out their attempt to complete a single = sentence.=20 > Looking at what NSEC3 offers, it goes beyond EU privacy regulations.=20 True, but the point I was making was that NSEC has been determined to be = incompatible with those regulations and so it is illogical to posit a = requirement to plan a transition from NSEC3 to NSEC absent either = contrary legal advice or a liklihood that the relevant laws will be = changed. > My raising this issue now could be seen as a means to delay=20 > NSEC3, in the sense that asking for "one more thing to be=20 > defined." The "victims" of this are zones that have reasons=20 > to not deploy NSEC,=20 No the victims would be the billion plus users of the Internet who have = waited far too long while this committee and others have traded concerns = over minutiae and constantly argued and re-argued the question of = whether to actually take account of real world operational constraints. = Meanwhile we have an infrastructure that everyone agrees is critical = that falls far short of providing acceptable security. Operational issues are an issue for registrars and the customers they = serve.=20 In DKIM we are building infrastructure that effectively presupposes a = certain level of security in the DNS infrastructure. I have no = involvement in the VeriSign work on DNSSEC but I am most certainly = working on infrastructures that presupose their timely deployment. I have been asking this WG to deliver a set of standards that the = registrars are prepared to deploy for six years now. Each time it = appears that delivery of a standard that the registrars are prepared to = deploy it has been trumped by procedural tactics and last minute = invention of 'operational requirements' that are not endorsed by a = registry planning to actually deploy the proposed scheme. I suggest that unless Ed plans to actually deploy NSEC3 he should not be = permitted to attach new requirements for advancement at this late stage = in the process. -- to unsubscribe send a message to namedroppers-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 May 18 15:26:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgo8O-0004Gs-Nk for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 15:26:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgo8O-0007Vm-Cn for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 15:26:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgo5h-000Hgw-9q for namedroppers-data@psg.com; Thu, 18 May 2006 19:23:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgo5g-000HgY-7Q for namedroppers@ops.ietf.org; Thu, 18 May 2006 19:23:20 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4IJN8tf016021; Thu, 18 May 2006 15:23:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 18 May 2006 15:21:03 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >If we didn't happen to already pass this station a long time ago, I've heard this statement quite often in IETF discussions. I think it is a symptom of what is wrong in the IETF approach to solving problems. Requirements shift. And sometimes people don't speak up until they can spend time on it. In particular, I didn't have time to slog through a lot of the early discussions on NSEC3, especially the crypto talk. I had to wait until it got to some level of solidity before I could imagine it in an operations setting. That's why I'm passing the station again. >Domain-holders have to choose between serving to NSEC-only resolvers or >NSEC/NSEC3 capable resolvers, where the tradeoff is between deployed base >and zone-enumeration. I think this is an unrealistic expectation. Once you force the server to choose among what dialect of clients it speaks to, you've split the network. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 18 19:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgrnq-0005PT-50 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:21:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgrnm-0005uH-BK for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:21:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgrkC-0003Yz-VS for namedroppers-data@psg.com; Thu, 18 May 2006 23:17:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgrkA-0003Ym-0d for namedroppers@ops.ietf.org; Thu, 18 May 2006 23:17:22 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 943C64035; Fri, 19 May 2006 01:17:08 +0200 (CEST) Date: Fri, 19 May 2006 01:17:08 +0200 From: bert hubert To: "Hallam-Baker, Phillip" Cc: Edward Lewis , Sam Weiler , namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism Message-ID: <20060518231706.GD13093@outpost.ds9a.nl> References: <198A730C2044DE4A96749D13E167AD37ABA8F7@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <198A730C2044DE4A96749D13E167AD37ABA8F7@MOU1WNEXMB04.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Thu, May 18, 2006 at 09:07:46AM -0700, Hallam-Baker, Phillip wrote: > No the victims would be the billion plus users of the Internet who have > waited far too long while this committee and others have traded concerns > over minutiae and constantly argued and re-argued the question of whether > to actually take account of real world operational constraints. Meanwhile > we have an infrastructure that everyone agrees is critical that falls far > short of providing acceptable security. Amen to that. So can we drop DNSSEC already? It has become so complex it is a running gag in many places. Duke Nukem Forever is rumoured to appear before DNSSEC is deployable. How about DNS2. It worked for POP3 and IPAM4. This would give us the ability to add a signable "empty recordset" answer and change the awkward semantics that have made DNSSEC the elephant it is today. Think how simple life would be if we could send out recordsets instead of sets of records, and sign such recordsets... We could also sign empty recordsets, which would Just Work. Registries could start offering DNS2 services, recursors would transparently translate back to DNS1 for the vast masses that can't yet talk DNS2. Etc etc. Think how much fun it would be to actually *achieve* something that could be deployed! The amount of effort sunk into DNSSEC would've given us DNS2, 3 and 4 by now.. Oh well, I can hope. Bert -- 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 May 18 19:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgrz6-0001U9-CN for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:32:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgrz5-0006n4-Vz for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:32:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgrxM-0004Kv-E3 for namedroppers-data@psg.com; Thu, 18 May 2006 23:31:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FgrxL-0004Kj-8n for namedroppers@ops.ietf.org; Thu, 18 May 2006 23:30:59 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 May 2006 00:30:57 +0100 X-IronPort-AV: i="4.05,143,1146438000"; d="scan'208"; a="3824040:sNHT31540048" In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Fri, 19 May 2006 01:31:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/19/2006 12:31:02 AM, Serialize complete at 05/19/2006 12:31:02 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Edward Lewis wrote on 05/18/2006 09:21:03 PM: > >If we didn't happen to already pass this station a long time ago, > > I've heard this statement quite often in IETF discussions. I think > it is a symptom of what is wrong in the IETF approach to solving > problems. Requirements shift. And sometimes people don't speak up > until they can spend time on it. Sure, it is easy for me to say "we're past that station", but what else is there. Should I blindly accept random requirements, stop process, go back to the drawing board, stall, convince others that this new item is really a new requirement ? I guess I did the following: Looked at what you're proposing, did not agree with what you're trying to propose. Trying to tell you why I don't agree with your proposal. As a result, I see most of my comments disappear. Note that we bend over backwards to satisfy the new 'secure during transition' requirement. We _have_ satisfied it. Maybe not to _your_ satisfaction, but we can only do so much. > In particular, I didn't have time to slog through a lot of the early > discussions on NSEC3, especially the crypto talk. Luckily, the rest of us did have _lots_ of time, especially for the crypto talk. > I had to wait > until it got to some level of solidity before I could imagine it in > an operations setting. That's why I'm passing the station again. What we're trying to do is built something that might actually work. What you're proposing is not realistic (read below why), and when I try to tell you that, you're not listening. Would you rather have the train wait until you catch up? > >Domain-holders have to choose between serving to NSEC-only resolvers or > >NSEC/NSEC3 capable resolvers, where the tradeoff is between deployed base > >and zone-enumeration. > > I think this is an unrealistic expectation. Once you force the > server to choose among what dialect of clients it speaks to, you've > split the network. Okay Ed, one more time: You are proposing to serve hashed data to avoid enumeration, and at the same time clear data to help those not understanding the hashed data, which leads to enumeration. As an analogy: Serving encrypted text to avoid evesdropping, while at the same time serving cleartext for those who do not understand the crypto algorithm. Sure this is technically feasible. Sure we did not test it in a test environment. Sure we need to built a lot of code for that. Sure it brings new complexities. We didn't do it because it makes no sense. It is the exact same reason why this is not a requirement: it makes no sense; and why I will try to make it an explicit NON-requirement when that station is going to be moved to the train again: because it makes no sense. Meanwhile, we have satisfied the 'secure during transition' requirement. Lets move on! Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 18 19:38:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgs4F-0003an-E0 for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:38:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgs4E-0007FM-5O for dnsext-archive@lists.ietf.org; Thu, 18 May 2006 19:38:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgs2w-0004kT-W2 for namedroppers-data@psg.com; Thu, 18 May 2006 23:36:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fgs2w-0004kE-2a for namedroppers@ops.ietf.org; Thu, 18 May 2006 23:36:46 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 May 2006 00:36:44 +0100 X-IronPort-AV: i="4.05,143,1146438000"; d="scan'208"; a="3824057:sNHT30655788" In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Fri, 19 May 2006 01:36:52 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/19/2006 12:36:50 AM, Serialize complete at 05/19/2006 12:36:50 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Roy Arends wrote on 05/19/2006 01:31:04 AM: > Edward Lewis wrote on 05/18/2006 09:21:03 PM: > > > In particular, I didn't have time to slog through a lot of the early > > discussions on NSEC3, especially the crypto talk. > > Luckily, the rest of us did have _lots_ of time, especially for the crypto > talk. Forgot the smiley: ;) 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 May 19 08:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh4B7-0007gj-Hk for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 08:34:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh4B6-00046s-88 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 08:34:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh47i-000HV6-9a for namedroppers-data@psg.com; Fri, 19 May 2006 12:30:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh47f-000HUl-Mh; Fri, 19 May 2006 12:30:27 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 19 May 2006 13:30:26 +0100 X-IronPort-AV: i="4.05,145,1146438000"; d="scan'208"; a="3425214:sNHT32761188" In-Reply-To: <200605180022.k4I0MSqR040831@drugs.dv.isc.org> To: Mark Andrews Cc: Ben Laurie , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: NSEC3 Dynamic Update (proposed) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Fri, 19 May 2006 14:30:31 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/19/2006 01:30:31 PM, Serialize complete at 05/19/2006 01:30:31 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Mark Andrews wrote on 05/18/2006 02:22:28 AM: > As background we were also discussing whether a zone should > be all opt-out or allow a mixture of opt-out and plain nsec3 > records. > > As far as I can tell there is no real benefit for a mixed > zone. You would have to work out which nsec3 spans a given > delegation that you wanted to be opted in would has hash into. I agree. There is no real benefit. > Also removing the ability to mix and match would simplify > update and the initial signing of the zone especially if > you didn't also have to track which delegations had to > provably exist or not. Signing needs an extra 'round' over all the added NSEC3 records to wether it covers hashes of unsigned delegations or not. There are many approaches to this, but they all lead to more work than just 'optout=0' or 'optout=1' for the entire zone. > The rules below give secure delegations probably exist and > insecure delegation do not probably exist for opt-out. A > zone would be opt-out / plain based on the setting of the > opt-out flag in apex's NSEC3 record. Provably, right ? > I think KISS is a good principle to apply here but it is > a trade off. I agree with all of the above. I think that Ben's 'dynamic update' text is sufficient. 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 May 19 08:34:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh4BD-0007po-P9 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 08:34:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh4BB-000471-Cn for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 08:34:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh45x-000HMv-Sz for namedroppers-data@psg.com; Fri, 19 May 2006 12:28:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh45x-000HMj-0b for namedroppers@ops.ietf.org; Fri, 19 May 2006 12:28:41 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Fh45v-0003pD-VF for namedroppers@ops.ietf.org; Fri, 19 May 2006 08:28:39 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 1A70513744; Fri, 19 May 2006 08:28:09 -0400 (EDT) Date: Fri, 19 May 2006 08:28:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism Message-ID: <20060519122803.GA3400@dba3> Reply-To: Andrew Sullivan References: <446B3B48.10501@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 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Wed, May 17, 2006 at 05:38:17PM -0400, Edward Lewis wrote: > Registries are supposed to be run in a reliable, smooth manner. > Expecting a registry to drop support for a feature and then pick it > up as if it were a flag day to all of its registrants violates this. > Flip-flopping is not smooth. While I am sympathetic to this observation (and all too painfully aware of it), I think there's a practical problem with it: the whole point of NSEC3 is to avoid a nasty consequence of NSEC. So if you think NSEC is dangerous today, what (aside from people clamouring "just sign it") changes that calculation in the time between today and the day NSEC3 is ready? That said, if someone has the magic necessary to make smooth bidirectional transistions possible, I'm all ears. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 19 11:32:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6xZ-0007Lj-63 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 11:32:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6xY-0007or-Py for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 11:32:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh6t2-0002oI-Uj for namedroppers-data@psg.com; Fri, 19 May 2006 15:27:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh6t1-0002o6-Ui for namedroppers@ops.ietf.org; Fri, 19 May 2006 15:27:32 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4JFRKSQ027381; Fri, 19 May 2006 11:27:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060519122803.GA3400@dba3> References: <446B3B48.10501@algroup.co.uk> <20060519122803.GA3400@dba3> Date: Fri, 19 May 2006 11:27:15 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 8:28 -0400 5/19/06, Andrew Sullivan wrote: >While I am sympathetic to this observation (and all too painfully >aware of it), I think there's a practical problem with it: the whole >point of NSEC3 is to avoid a nasty consequence of NSEC. So if you >think NSEC is dangerous today, what (aside from people clamouring >"just sign it") changes that calculation in the time between today >and the day NSEC3 is ready? The conventional wisdom of the NSEC3 developers is that NSEC3 can coexist with NSEC, that NSEC3 will only be used where it is necessary. I have two reasons to doubt that conventional wisdom. One is that it has been long said that we should hold no zone to be unusual, to be treated differently in the protocol. The other is that I don't know of any situation in which a protocol has two viable alternatives for a core function that remain in common use. To illustrate what I mean reverse map zones, widely delegated zones, enterprise zones all should get equal treatment under port 53. We do have OSPF an IS-IS as alternative internal routing protocols but they never interact. There is no reason to say that the conventional wisdom here is dead wrong. My doubt lays in the inability to see any precedent that supports the conventional wisdom. Given that, what "changes the calculation" regarding NSEC and NSEC3 over time? Regulation, customer requirements, lessons learned in trying to simplify operations come to mind. By "customer requirements" I mean organizations that set forth the operations requirements, like ICANN, and not the domain name registrants. E.g., what might be thought of as a NSEC3-agnostic zone today may be asked to take up NSEC3 in the future. >That said, if someone has the magic necessary to make smooth >bidirectional transistions possible, I'm all ears. With enough time and money, anything is possible. ;) It depends on where we place the workload. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 19 12:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7c4-0001uP-V4 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:14:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7c2-0001Sr-L6 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:14:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh7YR-0006Lq-5l for namedroppers-data@psg.com; Fri, 19 May 2006 16:10:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh7YP-0006Le-Ss for namedroppers@ops.ietf.org; Fri, 19 May 2006 16:10:17 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Fh7YO-00034X-KE; Fri, 19 May 2006 12:10:16 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id AA7DE13744; Fri, 19 May 2006 12:09:45 -0400 (EDT) Date: Fri, 19 May 2006 12:09:45 -0400 From: Andrew Sullivan To: Edward Lewis Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism Message-ID: <20060519160945.GE3400@dba3> Reply-To: Andrew Sullivan References: <446B3B48.10501@algroup.co.uk> <20060519122803.GA3400@dba3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Fri, May 19, 2006 at 11:27:15AM -0400, Edward Lewis wrote: > The conventional wisdom of the NSEC3 developers is that NSEC3 can > coexist with NSEC, that NSEC3 will only be used where it is necessary. > > I have two reasons to doubt that conventional wisdom. One is that it > has been long said that we should hold no zone to be unusual, to be > treated differently in the protocol. The other is that I don't know > of any situation in which a protocol has two viable alternatives for > a core function that remain in common use. That sounds like a reductio argument to the conclusion, "NSEC3 won't be everywhere, therefore NSEC3 won't be anywhere." But I doubt that's what you meant, so could you clarify? We know that we can't use NSEC in some applications -- if nothing else, it appears to cause trouble under some data protection laws. I also believe it to be inconsistent with some contractual obligations that some gTLDs work under. So some people will have to use something else. NSEC3 is that something else, and the availability of an NSEC3+NSEC mode for those zones won't help that, because those people are never going to be able to deploy NSEC anyway. Right? In that case, is your argument that they're never going to be able to deploy at all, because NSEC/NSEC3/NSEC chains won't work? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 19 12:22:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7kW-0003kr-Uz for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:22:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7kU-0001tt-Ks for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:22:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh7hn-00076M-Br for namedroppers-data@psg.com; Fri, 19 May 2006 16:19:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh7hm-000764-Aj for namedroppers@ops.ietf.org; Fri, 19 May 2006 16:19:58 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4JGJjeh027658; Fri, 19 May 2006 12:19:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060519160945.GE3400@dba3> References: <446B3B48.10501@algroup.co.uk> <20060519122803.GA3400@dba3> <20060519160945.GE3400@dba3> Date: Fri, 19 May 2006 12:19:45 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: Edward Lewis , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 12:09 -0400 5/19/06, Andrew Sullivan wrote: > >That sounds like a reductio argument to the conclusion, "NSEC3 won't >be everywhere, therefore NSEC3 won't be anywhere." But I doubt >that's what you meant, so could you clarify? That or NSEC3 will be everywhere and NSEC will fade out. >We know that we can't use NSEC in some applications -- if nothing >else, it appears to cause trouble under some data protection laws. I >also believe it to be inconsistent with some contractual obligations >that some gTLDs work under. So some people will have to use >something else. NSEC3 is that something else, and the availability >of an NSEC3+NSEC mode for those zones won't help that, because those >people are never going to be able to deploy NSEC anyway. Right? No. If a registry never does NSEC, then it'll not be bothered by NSEC+NSEC3. But for those who have to enter DNSSEC with NSEC, they will benefit from being able to provide both in responses. >In that case, is your argument that they're never going to be able to >deploy at all, because NSEC/NSEC3/NSEC chains won't work? I never said that NSEC/NSEC3/NSEC chains don't or won't work. They've not been demonstrated, tried, tested, etc. Why do people think I am saying NSEC3 is not going to work? There's a proposal for NSEC3. Due diligence is to hack at it to make sure it is solid. To do that you have to question the unclear parts for more definition and you have to test the clear parts. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 19 12:48:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh88y-0000d6-FD for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:48:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh88y-0003pW-5q for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 12:48:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh85L-00096i-QW for namedroppers-data@psg.com; Fri, 19 May 2006 16:44:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh85L-00096S-2c for namedroppers@ops.ietf.org; Fri, 19 May 2006 16:44:19 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Fh85J-0004M3-Ua for namedroppers@ops.ietf.org; Fri, 19 May 2006 12:44:17 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id E15E713744; Fri, 19 May 2006 12:43:46 -0400 (EDT) Date: Fri, 19 May 2006 12:43:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism Message-ID: <20060519164346.GG3400@dba3> Reply-To: Andrew Sullivan References: <446B3B48.10501@algroup.co.uk> <20060519122803.GA3400@dba3> <20060519160945.GE3400@dba3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Fri, May 19, 2006 at 12:19:45PM -0400, Edward Lewis wrote: > > That or NSEC3 will be everywhere and NSEC will fade out. [. . .] > No. If a registry never does NSEC, then it'll not be bothered by > NSEC+NSEC3. But for those who have to enter DNSSEC with NSEC, they > will benefit from being able to provide both in responses. Ok, so can I restate your argument this way: We will end up with NSEC or NESEC3, but not both. Some people must use NSEC3. Therefore, we'll end up with NSEC3. But some people must start before NSEC3 is ready, so they will have to start with NSEC. Therefore, it is necessary to plan now for a mechanism whereby servers may speak both NSEC and NSEC3 at the same time, for the inevitable transition period that we'll have to live with ? > Why do people think I am saying NSEC3 is not going to work? I'm not claiming anything at all about what you're saying: I'm trying to restate it such that it's clear to me what you've said (i.e. when you say "yes", I know what you're claiming). If I have your view right this time, I think the objections will come from the premise, "We'll have NSEC or NSEC3, but not both." I think someone has already argued in this thread that such a premise seems to rely pretty heavily on relatively rapid deployment of NSEC, and I am not convinced the evidence so far warrants such a belief. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 19 13:14:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8Yx-0004Zy-9u for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 13:14:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8Yx-0006ZL-02 for dnsext-archive@lists.ietf.org; Fri, 19 May 2006 13:14:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh8X8-000Bcq-CP for namedroppers-data@psg.com; Fri, 19 May 2006 17:13:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fh8X7-000BcV-De for namedroppers@ops.ietf.org; Fri, 19 May 2006 17:13:01 +0000 Received: from [10.31.32.55] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4JHCnEP027974; Fri, 19 May 2006 13:12:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060519164346.GG3400@dba3> References: <446B3B48.10501@algroup.co.uk> <20060519122803.GA3400@dba3> <20060519160945.GE3400@dba3> <20060519164346.GG3400@dba3> Date: Fri, 19 May 2006 13:12:45 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: Proposed NSEC/NSEC3 transition mechanism Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c I get the sense that folks think it is impossible to have a transition plan, therefore my request is a delaying tactic. My comment was driven by a discussion midway or late in the workshop when it was realized that no one had thought much about a plan. There were a few quickly sketched plans made then, but nothing well-baked, and nothing vetted. At 12:43 -0400 5/19/06, Andrew Sullivan wrote: >We will end up with NSEC or NESEC3, but not both. Some people must >use NSEC3. Therefore, we'll end up with NSEC3. But some people must >start before NSEC3 is ready, so they will have to start with NSEC. >Therefore, it is necessary to plan now for a mechanism whereby >servers may speak both NSEC and NSEC3 at the same time, for the >inevitable transition period that we'll have to live with Yes, more or less. I'd say "we will *probably* end up with..." But other than that, yes. Or to say it on the flip side, if we fail to consider transition, you place a large burden on the decision making process of zones ready to sign today - would you want to commit to NSEC now if it's possible that the rest of the world adopts NSEC3 in two years? >I'm not claiming anything at all about what you're saying: I'm trying >to restate it such that it's clear to me what you've said (i.e. when >you say "yes", I know what you're claiming). > >If I have your view right this time, I think the objections will come >from the premise, "We'll have NSEC or NSEC3, but not both." I think >someone has already argued in this thread that such a premise seems >to rely pretty heavily on relatively rapid deployment of NSEC, and I >am not convinced the evidence so far warrants such a belief. Let's just take the .SE and RIPE zones. What if they are the only ones running NSEC when NSEC3 rolls out? Do we force them to undo DNSSEC for a transition phase to be like the rest of the world as a penalty for being early adopters? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From asds@yahoo.co.jp Sat May 20 08:10:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhQIC-00086H-Sm for dnsext-archive@lists.ietf.org; Sat, 20 May 2006 08:10:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhQIC-0004j7-RS for dnsext-archive@lists.ietf.org; Sat, 20 May 2006 08:10:48 -0400 Received: from [221.200.232.50] (helo=lists.ietf.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FhQIB-0003aU-Jv for dnsext-archive@lists.ietf.org; Sat, 20 May 2006 08:10:48 -0400 To: From: =?iso-2022-jp?B?ZHNkcw==?= Subject: =?iso-2022-jp?B?GyRCNDBOOyQ3JF4kNyQ/GyhCOhskQjhmSnM5cBsoQjo=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!z(B $B!!%3%3$$$$$C$9$h!*(B $B!z(B $B!z!!!!!!(Bhttp://8888888hits.com/sogo/ $B!z(Bjionn@mail.china.com From owner-namedroppers@ops.ietf.org Sun May 21 04:54:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhjhk-0001ob-QY for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 04:54:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhjhi-0000Hw-Dz for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 04:54:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fhjby-000Msk-7z for namedroppers-data@psg.com; Sun, 21 May 2006 08:48:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fhjbx-000MsX-IV for namedroppers@ops.ietf.org; Sun, 21 May 2006 08:48:29 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k4L8mPdY008924; Sun, 21 May 2006 01:48:26 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 May 2006 01:48:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed NSEC/NSEC3 transition mechanism Date: Sun, 21 May 2006 01:48:20 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37ABAA35@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed NSEC/NSEC3 transition mechanism Thread-Index: AcZ7Z/HswMnB4LPzTjeHmYmoLtbqtABSRsLQ From: "Hallam-Baker, Phillip" To: "Edward Lewis" , "Andrew Sullivan" Cc: X-OriginalArrivalTime: 21 May 2006 08:48:19.0265 (UTC) FILETIME=[4EFA3B10:01C67CB3] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward Lewis > Let's just take the .SE and RIPE zones. What if they are the=20 > only ones running NSEC when NSEC3 rolls out? Do we force=20 > them to undo DNSSEC for a transition phase to be like the=20 > rest of the world as a penalty for being early adopters? If it is necessary to do so: yes. I don't think that it is necessary to develop a general transition = strategy that guarantees a successful transition from every possible = NSEC configuration to every possible NSEC3 configuration in order to = successfully transition those domains. I do not believe that the transition between NSEC and NSEC3 is any = different to any other DNSSEC transition. If the DNSSEC transition = mechanism is broken then its broken for all transitions. I do not = believe that any further theorising is going to be useful until we = collect experience of actually making a transition. If you are operating core Internet infrastructure then expect to be = required to make constant security upgrades.=20 We are under attack from organized crime. Their tactics keep changing. = We must be prepared to adapt and adjust our strategy in response. -- to unsubscribe send a message to namedroppers-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 May 21 05:39:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhkPC-0000JZ-8P for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 05:39:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhkP8-0001mN-Ty for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 05:39:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FhkNB-000Psx-5i for namedroppers-data@psg.com; Sun, 21 May 2006 09:37:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FhkN9-000Psi-21 for namedroppers@ops.ietf.org; Sun, 21 May 2006 09:37:15 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1A79D403B; Sun, 21 May 2006 11:37:02 +0200 (CEST) Date: Sun, 21 May 2006 11:37:02 +0200 From: bert hubert To: "Hallam-Baker, Phillip" Cc: Edward Lewis , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Proposed NSEC/NSEC3 transition mechanism Message-ID: <20060521093702.GA6303@outpost.ds9a.nl> References: <198A730C2044DE4A96749D13E167AD37ABAA35@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <198A730C2044DE4A96749D13E167AD37ABAA35@MOU1WNEXMB04.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Sun, May 21, 2006 at 01:48:20AM -0700, Hallam-Baker, Phillip wrote: > We are under attack from organized crime. Their tactics keep changing. We > must be prepared to adapt and adjust our strategy in response. We must be scaring the pants of these people with our non-zug-endet-hier algorithms. Also, to quote Kernighan: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? The applies just as well to programs as to protocols. Most people would agree DNSSEC is "as clever as we can be". It is at least for my limited brain. So who here honestly thinks we won't be needing NSEC4 or DNSSEC-ter? I'm still hoping for common sense to break out. Most of us here have been around the block more than once with protocol design, and most of us should therefore recognise the writing on the wall by now. Oh well.. -- 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 May 21 12:22:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhqh7-0003EK-K4 for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 12:22:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhqZJ-0004PJ-T2 for dnsext-archive@lists.ietf.org; Sun, 21 May 2006 12:14:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FhqVR-000NgA-ER for namedroppers-data@psg.com; Sun, 21 May 2006 16:10:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FhqVQ-000Nfy-Ni for namedroppers@ops.ietf.org; Sun, 21 May 2006 16:10:12 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k4LGA1i0022830; Sun, 21 May 2006 09:10:01 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 May 2006 09:09:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed NSEC/NSEC3 transition mechanism Date: Sun, 21 May 2006 09:09:44 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37ABAA39@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed NSEC/NSEC3 transition mechanism Thread-Index: AcZ8ujpnMD2KQQe6R+2+60LMuF8esQANAgjw From: "Hallam-Baker, Phillip" To: "bert hubert" Cc: "Edward Lewis" , "Andrew Sullivan" , X-OriginalArrivalTime: 21 May 2006 16:09:54.0481 (UTC) FILETIME=[FF5B5A10:01C67CF0] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > From: bert hubert [mailto:bert.hubert@netherlabs.nl]=20 > We must be scaring the pants of these people with our=20 > non-zug-endet-hier algorithms. >=20 > Also, to quote Kernighan:=20 >=20 > Everyone knows that debugging is twice as hard as=20 > writing a program > in the first place. So if you are as clever as you can=20 > be when you > write it, how will you ever debug it? >=20 > The applies just as well to programs as to protocols. Most=20 > people would agree DNSSEC is "as clever as we can be". It is=20 > at least for my limited brain. Fortunately when we debug the program we have the help of the computer = which has a much better understanding of what its response to the = commands we issue will be than we have ourselves. When debugging a program I start with a very clear idea of what each = part of the program is intended to do. I then design test procedures = that are intended to verify that it does in fact perform as I expect. It seems to me that at this stage the group has captured as much = understanding of the problem that can be usefully gained by theory. It = is time to test this particular module. Six years is ample time to have = waited. Requirements capture is not the same as debugging. Until you build the = system and observe how it is used by P-E-O-P-L-E you won't understand = the real requirements. We are dealling with a bunch of people that are = not even users, they are wreckers. > So who here honestly thinks we won't be needing NSEC4 or DNSSEC-ter? We could have got to this point five years ago if people had been = willing to accept the validity of the use cases and requirements raised. = I find it somewhat ironic to see that the possibility we might not have = captured every imaginable requirement and fulfilled it is being used to = argue against this attempt to meet requirements that have been = identified. If you have a requirement that you think is a show stopper then raise = it. But don't ask for the whole world to stop while we wait on the = possibility that you might come up with something. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 22 03:08:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi4WQ-00022j-W6 for dnsext-archive@lists.ietf.org; Mon, 22 May 2006 03:08:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi4WP-0000OJ-FC for dnsext-archive@lists.ietf.org; Mon, 22 May 2006 03:08:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi4Nr-0006Vr-Av for namedroppers-data@psg.com; Mon, 22 May 2006 06:59:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fi4Np-0006Va-Hx for namedroppers@ops.ietf.org; Mon, 22 May 2006 06:59: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 k4M6wFbW085022 for ; Mon, 22 May 2006 08:59:14 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-70-322751636" Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Date: Mon, 22 May 2006 08:59:19 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-70-322751636 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed For your information Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: May 19, 2006 6:00:01 AM GMT+02:00 > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF > Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 66th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-70-322751636 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. iD8DBQFEcWFItN/ca3YJIocRAnrdAJsHVU0en1VwUqHIKFEaKCRXoMNZtQCeJEdK vvX+GFJBuYcMtDfEHvds4ys= =LiPR -----END PGP SIGNATURE----- --Apple-Mail-70-322751636-- -- to unsubscribe send a message to namedroppers-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 May 23 04:56:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSgy-0004P9-2D for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 04:56:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSgw-0003hw-Na for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 04:56:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiSbQ-0006sC-Ub for namedroppers-data@psg.com; Tue, 23 May 2006 08:50:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiSbP-0006rf-AF for namedroppers@ops.ietf.org; Tue, 23 May 2006 08:50:55 +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 k4N8onWl036098; Tue, 23 May 2006 10:50:50 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-415840417" Message-Id: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> Cc: Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: draft-ietf-dnsext-nsid issues to be reviewed Date: Tue, 23 May 2006 10:50:48 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7-415840417 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear colleagues, Two issues are identified during review by the AD, Mark. I would like to address them here and see if there is consensus. These are the issues: > 1. The document is not clear in who is supposed to be decoding the > nsid. While it is clear that it may be populated in a number of > ways, it needs to be more clear that only the one populating the > nsid field will be the one ultimately decoding what was placed in it. The proposal is to add text. My (in the role of document shepherd) straw-man proposal is to add something along the lines of the following. OLD: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. NEW: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content as long as the content is unique and the server administrator is able to match the NSID to server instances. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. > 2. There are a lot of methods listed for populating the nsid. I > [OK: this is Mark speaking] would like to at a minimum see manual > configuration listed as a "MUST-Implement," I would also like to > ask the working group if it can choose one automatic method as a > "MUST-Implement" so as to obtain some degree of commonality when > not programming these by hand. I think it is a good idea, but given > that this value is never to be decoded between implementation > beyond handling as opaque data, I will not press the issue. Is there consensus to add such a "MUST implement a specific automated method"? Silence will be interpreted as that there is such consensus and that the following text modifications will be made (enforcing manual configuration but not choosing an automated method). Silence is not a good way to convince the IESG though. In section 2.3: OLD: The OPTION-DATA for the NSID option is an opaque byte string the semantics of which are deliberately left outside the protocol. NEW: The OPTION-DATA for the NSID option is an opaque byte string the semantics of which are deliberately left outside the protocol. Implementations MUST implement manual configuration of the NSDID string. Obviously alternative text is welcomed but please submit in "Old", "New" format. I would like to close this issue in 2 weeks from now. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-7-415840417 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. iD8DBQFEcszptN/ca3YJIocRAidlAJ9bcUycmJLXzTyAdJEcwuS9zAeGvwCg2dcv SegCVAjXH4d6Q/ABfz4tVYE= =9NJH -----END PGP SIGNATURE----- --Apple-Mail-7-415840417-- -- to unsubscribe send a message to namedroppers-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 May 23 07:08:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUkK-0000OP-CJ for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 07:08:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiUkJ-0001Vx-1d for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 07:08:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiUhO-000HMn-Df for namedroppers-data@psg.com; Tue, 23 May 2006 11:05:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiUhL-000HLN-TM for namedroppers@ops.ietf.org; Tue, 23 May 2006 11:05:12 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FiUhJ-0004qN-Pn; Tue, 23 May 2006 07:05:09 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 669A013744; Tue, 23 May 2006 07:04:36 -0400 (EDT) Date: Tue, 23 May 2006 07:04:36 -0400 From: Andrew Sullivan To: "Olaf M. Kolkman" Cc: Namedroppers , Mark Townsley Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed Message-ID: <20060523110436.GB1676@dba3> Reply-To: Andrew Sullivan References: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On Tue, May 23, 2006 at 10:50:48AM +0200, Olaf M. Kolkman wrote: > NEW > 3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique and the server > administrator > is able to match the NSID to server instances. This > section describe some of the kinds of data that server > administrators > might choose to provide as the content of the NSID option, and > explains the reasoning behind choosing a simple opaque byte string. > Does the requirement for uniqueness introduce new problems? Would it be enough to say, "as long as the content is distinctive enough that the server administrator is able to match. . ."? (I'm not opposed to the proposed text, but "unique" is a strong word.) > Is there consensus to add such a "MUST implement a specific automated > method"? What about SHOULD? I'm leery of MUST, especially in conjunction with the uniqueness constraint above. > NEW: > The OPTION-DATA for the NSID option is an opaque byte string the > semantics of which are deliberately left outside the protocol. > Implementations MUST implement manual configuration of the NSDID string. I support this text, at least. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 23 07:28:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiV4F-0000hT-Bp for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 07:28:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiV49-0002UZ-1Z for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 07:28:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiV1q-000Iy5-Nh for namedroppers-data@psg.com; Tue, 23 May 2006 11:26:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FiV1p-000Ixh-C6 for namedroppers@ops.ietf.org; Tue, 23 May 2006 11:26:21 +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 k4NBQIVo017973; Tue, 23 May 2006 13:26:18 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id k4NBQIm14219; Tue, 23 May 2006 13:26:18 +0200 (MEST) Message-Id: <200605231126.k4NBQIm14219@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG From: Peter Koch Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed In-reply-to: Your message of "Tue, 23 May 2006 10:50:48 +0200." <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14216.1148383566.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Tue, 23 May 2006 13:26:18 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Olaf M. Kolkman wrote: > 3.1. The NSID Payload > > It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique and the server administrator > is able to match the NSID to server instances. OK with me (although I must agree with Andrew, seeing his message coming in). If the server administrator is able to do the match, "uniqueness" is probably too strong. > Is there consensus to add such a "MUST implement a specific automated > method"? I am not convinced that that would serve a useful purpose. The data is entered by the server administrator, published and then transferred back to the very server administrator. So this is interoperability with thyself? Name server configuration is very heterogeneous anyway, so unification for this single issue doesn't seem to lead very far. On the other hand, explicitly favoring one nsid generation method might discourage implementation of more sophisticated ones. Also, the configuration issue is not touched in . -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 23 13:34:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fialm-0007Q8-K4 for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 13:34:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiall-0001kv-Ak for dnsext-archive@lists.ietf.org; Tue, 23 May 2006 13:34:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fiai7-000KB6-OF for namedroppers-data@psg.com; Tue, 23 May 2006 17:30:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fiai6-000KAT-Sj for namedroppers@ops.ietf.org; Tue, 23 May 2006 17:30:23 +0000 Received: from [10.31.32.118] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k4NHUAaY007178; Tue, 23 May 2006 13:30:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> References: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> Date: Tue, 23 May 2006 13:28:57 -0400 To: Namedroppers From: Edward Lewis Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed Cc: Mark Townsley , ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 10:50 +0200 5/23/06, Olaf M. Kolkman wrote: >NEW: > >3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique and the server administrator > is able to match the NSID to server instances. This > section describe some of the kinds of data that server administrators > might choose to provide as the content of the NSID option, and > explains the reasoning behind choosing a simple opaque byte string. Unique with respect to what? "This section describe" -> "This section describes" "NSID option/content" -> "NSID Payload" in multiple places (??) >In section 2.3: > >NEW: >The OPTION-DATA for the NSID option is an opaque byte string the semantics of >which are deliberately left outside the protocol. Implementations MUST >implement manual configuration of the NSDID string. Once again, I'm at a loss to understand "MUST implement" when there is no enforcement of IETF decrees. So I can't come up with a comment. "NSDID" -> "NSID" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 May 24 19:27:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2ky-0005tB-80 for dnsext-archive@lists.ietf.org; Wed, 24 May 2006 19:27:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj2kw-0000vV-Ux for dnsext-archive@lists.ietf.org; Wed, 24 May 2006 19:27:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj2ew-00045S-8E for namedroppers-data@psg.com; Wed, 24 May 2006 23:20:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [64.233.166.180] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj2ev-00045E-Kn for namedroppers@ops.ietf.org; Wed, 24 May 2006 23:20:57 +0000 Received: by py-out-1112.google.com with SMTP id b36so2113219pyb for ; Wed, 24 May 2006 16:20:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bgVOrHfO2BJmfpmQ6w1js/wqM1gQ5QO8PkNMpWrL6YPky1BsjvCY9Us6y9CPm58cCOfv+CShQ3ZtlKelOiXaUQD3mujC5muEGiM/mNFBFJeP4lgXN1RT0S7N4MpF3YWtO/BTIkyzP+Ttba5I+ACvXNYwfZTsO5SHWD1GyVDY/wM= Received: by 10.35.105.18 with SMTP id h18mr1654852pym; Wed, 24 May 2006 16:20:56 -0700 (PDT) Received: by 10.35.83.15 with HTTP; Wed, 24 May 2006 16:20:56 -0700 (PDT) Message-ID: <487354f10605241620t1c8b3c56sf123cdd6cd658acc@mail.gmail.com> Date: Thu, 25 May 2006 01:20:56 +0200 From: "Robert Martin-Legene" To: "Roy Arends" Subject: Re: SOA records in negative responses Cc: namedroppers@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On 15/05/06, Roy Arends wrote: > Negative responses may have SOA records included so the cache has an > indication for the time it should cache a negative response. Hello Roy. I think some people want / use it for finding zone cuts. I have no practical experience if it's worth anything, but I believe Paul had some input at IETF64.. or was it Mark? -- Robert, .dk -- to unsubscribe send a message to namedroppers-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 May 24 20:50:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj43a-00075o-7v for dnsext-archive@lists.ietf.org; Wed, 24 May 2006 20:50:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj43U-0006VY-VJ for dnsext-archive@lists.ietf.org; Wed, 24 May 2006 20:50:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj3zt-0009Gl-To for namedroppers-data@psg.com; Thu, 25 May 2006 00:46:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fj3zt-0009GZ-87 for namedroppers@ops.ietf.org; Thu, 25 May 2006 00:46:41 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 18D05E60E5 for ; Thu, 25 May 2006 00:46: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.4) with ESMTP id k4P0kUkV001660; Thu, 25 May 2006 10:46:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200605250046.k4P0kUkV001660@drugs.dv.isc.org> To: "Robert Martin-Legene" Cc: "Roy Arends" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: SOA records in negative responses In-reply-to: Your message of "Thu, 25 May 2006 01:20:56 +0200." <487354f10605241620t1c8b3c56sf123cdd6cd658acc@mail.gmail.com> Date: Thu, 25 May 2006 10:46:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > On 15/05/06, Roy Arends wrote: > > Negative responses may have SOA records included so the cache has an > > indication for the time it should cache a negative response. > > Hello Roy. > > I think some people want / use it for finding zone cuts. I have no > practical experience if it's worth anything, but I believe Paul had > some input at IETF64.. or was it Mark? draft-andrews-dnsext-soa-discovery-00 I need to revive it, possibly by requesting publication, as it expired April 14, 2006. 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 Thu May 25 05:07:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjBof-0002WY-Gy for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 05:07:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjBoW-0005ob-7a for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 05:07:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjBkE-000IHO-NH for namedroppers-data@psg.com; Thu, 25 May 2006 09:03:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjBkB-000IH7-Vf for namedroppers@ops.ietf.org; Thu, 25 May 2006 09:03:00 +0000 Received: from [81.149.132.66] (account jim HELO [192.168.0.3]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 21211; Thu, 25 May 2006 10:02:57 +0100 In-Reply-To: <487354f10605241620t1c8b3c56sf123cdd6cd658acc@mail.gmail.com> References: <487354f10605241620t1c8b3c56sf123cdd6cd658acc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Roy Arends" , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: SOA records in negative responses Date: Thu, 25 May 2006 10:02:54 +0100 To: Robert Martin-Legene X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On May 25, 2006, at 00:20, Robert Martin-Legene wrote: > On 15/05/06, Roy Arends wrote: >> Negative responses may have SOA records included so the cache has an >> indication for the time it should cache a negative response. > > I think some people want / use it for finding zone cuts. I have no > practical experience if it's worth anything, but I believe Paul had > some input at IETF64.. or was it Mark? There is a draft in the ENUM WG -- draft-ietf-enum-void-02.txt -- that relies on this technique. The idea was a lookup for an undelegated number would get an NXDOMAIN response containing the SOA for the zone cut. A lookup for the name of that zone cut could identify a default SIP server or whatever. The intention is to avoid the evils of wildcards. -- to unsubscribe send a message to namedroppers-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 May 25 07:02:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDcJ-0008Ec-Rn for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 07:02:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjDcH-0005sX-JB for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 07:02:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjDYg-0000N5-BR for namedroppers-data@psg.com; Thu, 25 May 2006 10:59:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjDYd-0000MK-IJ for namedroppers@ops.ietf.org; Thu, 25 May 2006 10:59:11 +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 k4PAwuPJ070185; Thu, 25 May 2006 12:58:57 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-596325175" Message-Id: Cc: Namedroppers , Edward Lewis Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) Date: Thu, 25 May 2006 12:58:53 +0200 To: Roy Arends X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-596325175 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Roy and colleagues, Would anybody care to write a comprehensive conclusion of this thread that can go into dnssec-bis-updates. ("Roy and colleagues" is a hint :-) ) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-25-596325175 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. iD4DBQFEdY3ttN/ca3YJIocRAqJlAJwMsA+lOyNB4zfHC39X308Ypb1KOwCY67WJ QCxdSolyV4EtljOmk08ALg== =tmox -----END PGP SIGNATURE----- --Apple-Mail-25-596325175-- -- to unsubscribe send a message to namedroppers-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 May 25 08:58:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFQ2-0003xV-If for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 08:58:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFQ1-0007GX-9t for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 08:58:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFNA-0008fG-9U for namedroppers-data@psg.com; Thu, 25 May 2006 12:55:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFN9-0008ep-Do for namedroppers@ops.ietf.org; Thu, 25 May 2006 12:55:27 +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 k4PCtFi3071999; Thu, 25 May 2006 14:55:15 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-603304680" Message-Id: Cc: "Namedroppers" Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 5: Embedded requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Thu, 25 May 2006 14:55:12 +0200 To: Scott Rose X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-603304680 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed While reading up on the ISSUES on the rollover draft (we should try to get those to closure) I noticed: >> DESCRIPTION: >> >> Added the following text to the "Timeliness" requirement: >> Operators of security-aware resolvers using RR(s) from that >> zone as Trust Anchors need to acquire new and remove revoked >> Trust Anchors such that no old key is used for long after >> revocation. >> > > I support this requirement in principle, but I am unsure what a > "long time > period" would be. How about the TTL of the DNSKEY RR? Just > thinking out > loud, but when a rollover is seen, the old trust anchor should be > purged as > if it were part of the cache at that point. > I think that in this context "long" means much much longer than the time it took for the TTL to expire. Hard to put a quantitative number on but what about "one or two orders of magnitude longer than the SOA expiry parameter" or alternatively "during the expected lifetime of the zone" (another can of definition worms) No hats. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-5-603304680 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. iD8DBQFEdakxtN/ca3YJIocRAhslAKDDygfRK4cPJxTdf7bUwfPtrMk1tQCg3IBd R5l7lj7XO+JXjveFVOwU9l0= =7zjm -----END PGP SIGNATURE----- --Apple-Mail-5-603304680-- -- to unsubscribe send a message to namedroppers-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 May 25 09:17:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFit-0006Le-TB for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:17:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFit-0008Ng-RG for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:17:55 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjFYH-0008Am-LD for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:06:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFVu-0009VY-Bg for namedroppers-data@psg.com; Thu, 25 May 2006 13:04:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFVt-0009VM-Kf for namedroppers@ops.ietf.org; Thu, 25 May 2006 13: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 k4PD4QRh072121; Thu, 25 May 2006 15:04:26 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4438358E.40405@algroup.co.uk> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> <4438358E.40405@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-603856194" Message-Id: <2EA8841E-7E88-43C1-B041-4B256D9D4F42@NLnetLabs.nl> Cc: Suresh Krishnaswamy , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 6: Requirements in draft-moreau-dnsext-tak-req-00, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Thu, 25 May 2006 15:04:23 +0200 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -1.9 (-) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6-603856194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 9, 2006, at 12:13 AM, Ben Laurie wrote: >> >> 5.11. Non-degrading Trust >> >> The method or methods used for Trust Anchor Distribution MUST be >> deemed sufficiently trustworthy by the operator of the security- >> aware >> resolver to ensure source authenticity and integrity of the new >> RR(s) >> to maintain the Initial Trust Relationship required to designate >> those RR(s) as Trust Anchor(s). > > Woah! This appears to make it impossible to implement any kind of > federated solution (for example, my I-D on key seeding, which could > also > be used for rollover). It would also rule out changing the > authority for > the keys. That is not how I read the initial proposed text. I read this proposed requirement as (paraphrased): "The method must provide sufficient means to ensure authenticity and integrity so that by the existing trust relation does not degrade by performing the rollover." If that is a correct interpretation it does not rule out a federated solution. (Besides, if the requirements are such that they rule out a federated solution because another proposal matches the requirements better, then so be it. that is the reason we try to get the requirements finalized). No hats, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-6-603856194 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. iD8DBQFEdatYtN/ca3YJIocRAqK8AKC1evttsYvLwyytfoBDl/B9R/exJACgx0HD kc8z28Vx34D3JaA9S40GIwg= =/J5H -----END PGP SIGNATURE----- --Apple-Mail-6-603856194-- -- to unsubscribe send a message to namedroppers-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 May 25 09:18:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFjo-00077X-8s for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:18:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFjn-0008QH-0F for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:18:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFhJ-000ARl-2o for namedroppers-data@psg.com; Thu, 25 May 2006 13:16:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFhI-000ART-1B; Thu, 25 May 2006 13:16:16 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 25 May 2006 14:16:11 +0100 X-IronPort-AV: i="4.05,171,1146438000"; d="scan'208"; a="3478851:sNHT27735036" In-Reply-To: To: "Olaf M. Kolkman" Cc: Edward Lewis , Namedroppers , owner-namedroppers@ops.ietf.org Subject: Re: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Thu, 25 May 2006 15:16:08 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/25/2006 02:16:09 PM, Serialize complete at 05/25/2006 02:16:09 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 owner-namedroppers@ops.ietf.org wrote on 05/25/2006 12:58:53 PM: > > Roy and colleagues, > > Would anybody care to write a comprehensive conclusion of this thread > that can go into dnssec-bis-updates. I will give it a try. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 25 09:31:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFvv-000643-G1 for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:31:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFvu-0000mN-3j for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 09:31:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFtv-000BPp-W1 for namedroppers-data@psg.com; Thu, 25 May 2006 13:29:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjFtv-000BOS-3w for namedroppers@ops.ietf.org; Thu, 25 May 2006 13:29:19 +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 k4PDStxc072576; Thu, 25 May 2006 15:28:56 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <2EA8841E-7E88-43C1-B041-4B256D9D4F42@NLnetLabs.nl> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> <4438358E.40405@algroup.co.uk> <2EA8841E-7E88-43C1-B041-4B256D9D4F42@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-605325998" Message-Id: Cc: Ben Laurie , Suresh Krishnaswamy , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 6: Requirements in draft-moreau-dnsext-tak-req-00, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Thu, 25 May 2006 15:28:53 +0200 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7-605325998 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Ooops.... I seem to be reopening a closed issues only because I missed Suresh' excellent concluding mail on the list of issues (http://ops.ietf.org/ lists/namedroppers/namedroppers.2006/msg00624.html). Now I reread the archive and I can add that Suresh's mail actually captures the consensus on the list. There were two further issues raised in that mail that were not further discussed. I propose that if there are no furhter comments on that we close the issues list and go for last call. Note is taken of Thierry's posting. I'll reply to that note separately. --Olaf On May 25, 2006, at 3:04 PM, Olaf M. Kolkman wrote: > > On Apr 9, 2006, at 12:13 AM, Ben Laurie wrote: > >>> >>> 5.11. Non-degrading Trust >>> >>> The method or methods used for Trust Anchor Distribution MUST be >>> deemed sufficiently trustworthy by the operator of the >>> security-aware >>> resolver to ensure source authenticity and integrity of the >>> new RR(s) >>> to maintain the Initial Trust Relationship required to designate >>> those RR(s) as Trust Anchor(s). >> >> Woah! This appears to make it impossible to implement any kind of >> federated solution (for example, my I-D on key seeding, which >> could also >> be used for rollover). It would also rule out changing the >> authority for >> the keys. > > That is not how I read the initial proposed text. > > I read this proposed requirement as (paraphrased): "The method must > provide sufficient means to ensure authenticity and integrity so > that by the existing trust relation does not degrade by performing > the rollover." > > If that is a correct interpretation it does not rule out a > federated solution. (Besides, if the requirements are such that > they rule out a federated solution because another proposal matches > the requirements better, then so be it. that is the reason we try > to get the requirements finalized). > > > No hats, > > --Olaf > > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-7-605325998 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. iD8DBQFEdbEWtN/ca3YJIocRArLQAKCmiU2I0/fqrqMI4DC3b/sBtI1+ZACgktvN EbDyyCBC2RZkrw6//36Gfxc= =nzjV -----END PGP SIGNATURE----- --Apple-Mail-7-605325998-- -- to unsubscribe send a message to namedroppers-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 May 25 10:06:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGTT-0007wM-GB for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:06:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGTP-0004VB-2I for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:06:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGQZ-000E3v-Bv for namedroppers-data@psg.com; Thu, 25 May 2006 14:03:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGQW-000E3d-Im for namedroppers@ops.ietf.org; Thu, 25 May 2006 14:03:00 +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 k4PE2pOr072990; Thu, 25 May 2006 16:02:52 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <44634629.4050500@connotech.com> References: <44634629.4050500@connotech.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-607361248" Message-Id: <9255E708-5BEA-4D47-A190-0B0EC37E8325@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-01.txt Date: Thu, 25 May 2006 16:02:49 +0200 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9-607361248 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On May 11, 2006, at 4:11 PM, Thierry Moreau wrote: > Dear co-chairs and wg members: > > I regret to post the present message against progression of DNSEXT > WG document draft-ietf-dnsext-rollover-requirements-01. I see two > difficulties with this draft, related to the IETF document > development process. Although we have not issued a last call yet I will take this note as input for a "nay" during last call. > The wording used in the section 5.2. (No Intellectual Property > Encumbrance) is such that the DNSEXT WG commits itself to make > factual verifications about the presence and/or validity of IPR > claims, which is a WG activity not compliant with RFC3979. I think that Wes Hardaker's suggested modification to the text fixes this; the working group then only has to check on "known encumbrance" which is essentially "verifying against the IPR database". > > The other issue with the document is that it goes beyond the DNSEXT > chartered work. Specifically, the charter mandates DNSEXT to > "Define a method for automated rollover of trust-anchors configured > in validating resolvers." Instead, the requirements document > address trust anchor key management on a broader perspective, as if > the charter might be revised as a consequence of revisiting the > trust anchor key functions in the DNSSEC protocol specifications. > > In going beyond its specific automated rollover mandate, the DNSEXT > envisions solutions outside of DNS protocol extensions, again in > possible conflict with the DNSEXT charter. You have lifted a specific line from the charter: "a method for automated rollover of trust-anchors configured in validating resolvers." I would like to quote the full context: The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. In my opinion the working group is not overarching since we are trying to sort out solutions for DNSSEC deployment issues that may require protocol modifications. > There might be a group willingness to proceed along the lines > explained above. However, the IETF standards development process is > a structured activity, and wandering of a WG outside the process > rules and/or its chartered work may be coerced by the groups in > charge of IETF activities overseeing (if I understand correctly, > this would be the IESG if and when the draft is approved at the WG > level). > > What should have been done in the preparation for a requirement > document for automated trust anchor key rollover is to define the > very issues as faced in the DNSSEC protocol environment, > contemplating the set of possible DNS protocol extensions for > rollover purposes, with the known limitations of the DNS > architecture. As a consequence, the requirements document might > have come to inescapable security considerations expected from any > trust anchor key rollover solution. If I recall correctly, the WG > chairs expressed the view that the requirement should also define > "metrics" against which trust anchor key rollover solutions would > be evaluated. We did. I would like to ask the working group if they think that that will be a useful exercise. Personally I think it be a difficult task. I propose that we "fix" the rollover requirements document and that we start looking at the separate proposals and see which ones meet which requirements. From that we can probably isolate 1 or 2 on which we then will further debate. > > These issues were privately raised to the DNSEXT WG co-chairs, > without feedback. In WG discussion about the previous version of > the document draft-ietf-dnsext-rollover-requirements-00, I > expressed my opinion about the section 5.2. (No Intellectual > Property Encumbrance), and I otherwise abstained from making > contributions towards advancement of the draft, based on the > assumption that the WG discussions on a draft going beyond the WG > charter would be unproductive. I have invited you to contribute to the working groups requirement document. I understand that you consciously abstained, so noted. thanks, --Olaf Kolkman ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-9-607361248 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. iD8DBQFEdbkJtN/ca3YJIocRAm8eAKC8X5T13XqOiz3tTynGZQ9N00SoeACeJiZX xx80Ua/sZriekQZ2vQvBaSo= =Zq5y -----END PGP SIGNATURE----- --Apple-Mail-9-607361248-- -- to unsubscribe send a message to namedroppers-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 May 25 10:07:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGUR-0002QX-Bx for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:07:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGUL-0004Xy-2u for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:07:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGT1-000EGg-K1 for namedroppers-data@psg.com; Thu, 25 May 2006 14:05:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGSz-000EFZ-5w for namedroppers@ops.ietf.org; Thu, 25 May 2006 14:05:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A71E311425 for ; Thu, 25 May 2006 14:05:32 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: SOA records in negative responses In-Reply-To: Your message of "Thu, 25 May 2006 10:02:54 +0100." References: <487354f10605241620t1c8b3c56sf123cdd6cd658acc@mail.gmail.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 25 May 2006 14:05:32 +0000 Message-ID: <88977.1148565932@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > > I think some people want / use it for finding zone cuts. I have no > > practical experience if it's worth anything, but I believe Paul had > > some input at IETF64.. or was it Mark? mark's draft on this is excellent. much better than the comments in my code where the technique was first worked out, and more accessible too. (see bind8/src/lib/resolv/res_findzonecut.c for history.) > There is a draft in the ENUM WG -- draft-ietf-enum-void-02.txt -- > that relies on this technique. The idea was a lookup for an undelegated > number would get an NXDOMAIN response containing the SOA for the zone > cut. A lookup for the name of that zone cut could identify a default SIP > server or whatever. The intention is to avoid the evils of wildcards. lovely. somebody should tell the SPF people though. dns doesn't subclass well, but it can be done. -- to unsubscribe send a message to namedroppers-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 May 25 12:37:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIqV-0001VR-7L for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 12:37:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGnz-0005RW-2U for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:27:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjGjQ-0000bU-IC for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 10:22:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGhF-000FR3-33 for namedroppers-data@psg.com; Thu, 25 May 2006 14:20:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.133.34] (helo=mail11.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjGhE-000FQo-2W for namedroppers@ops.ietf.org; Thu, 25 May 2006 14:20:16 +0000 Received: by mail11.mdx.safepages.com (Postfix, from userid 1012) id D8E3DA0D65; Thu, 25 May 2006 14:20:19 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.131]) by mail11.mdx.safepages.com (Postfix) with ESMTP id 0BC55A0790; Thu, 25 May 2006 14:20:07 +0000 (GMT) Message-ID: <4475BD3C.1020905@connotech.com> Date: Thu, 25 May 2006 10:20: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: "Olaf M. Kolkman" CC: Ben Laurie , Suresh Krishnaswamy , Namedroppers Subject: Re: ISSUE 6: Requirements in draft-moreau-dnsext-tak-req-00, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> <4438358E.40405@algroup.co.uk> <2EA8841E-7E88-43C1-B041-4B256D9D4F42@NLnetLabs.nl> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Olaf M. Kolkman wrote: > > Ooops.... > > I seem to be reopening a closed issues only because I missed Suresh' > excellent concluding mail on the list of issues (http://ops.ietf.org/ > lists/namedroppers/namedroppers.2006/msg00624.html). Now I reread the > archive and I can add that Suresh's mail actually captures the > consensus on the list. > The relevant excerpt is "There was one vote against including non-degrading trust as a requirement. Since no one seemed to disagree with this, the action is to remove "non-degrading trust" as a requirement." Accordingly, a TAK solution that allows degrading trust over a sequence of rollover events is aceptable. Sorry for repeating an argument already made, I deliberately abstain from contributing to the progress on draft-ietf-dnsext-rollover-requirements, based on the assumption that these discussions would be unproductive. 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 May 25 14:53:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKxS-0000aP-Ow for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 14:53:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKxN-000417-H1 for dnsext-archive@lists.ietf.org; Thu, 25 May 2006 14:53:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjKsJ-0009RA-K6 for namedroppers-data@psg.com; Thu, 25 May 2006 18:47:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [195.30.85.225] (helo=io.link-m.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjKsH-0009Qv-2B for namedroppers@ops.ietf.org; Thu, 25 May 2006 18:47:57 +0000 Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Thu, 25 May 2006 18:47:53 +0000 id 00003E5D.4475FBD9.000003A7 From: Julian Mehnle To: namedroppers@ops.ietf.org Subject: Re: SOA records in negative responses Date: Thu, 25 May 2006 18:47:50 +0000 User-Agent: KMail/1.9.1 References: <88977.1148565932@sa.vix.com> In-Reply-To: <88977.1148565932@sa.vix.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8094527.cgOJRtSmPS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605251847.51487.julian@mehnle.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --nextPart8094527.cgOJRtSmPS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Paul Vixie wrote: > > There is a draft in the ENUM WG -- draft-ietf-enum-void-02.txt -- > > that relies on this technique. The idea was a lookup for an=20 > > undelegated number would get an NXDOMAIN response containing the SOA=20 > > for the zone cut. A lookup for the name of that zone cut could=20 > > identify a default SIP server or whatever. The intention is to avoid=20 > > the evils of wildcards. > > lovely. somebody should tell the SPF people though. dns doesn't > subclass well, but it can be done. I have been following this thread and will bring it to the attention of=20 spf-discuss@v2.listbox.com. --nextPart8094527.cgOJRtSmPS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEdfvXwL7PKlBZWjsRAqgFAKCOUXCy9QZfUXVFOMwg6CdosUsobgCg3KUu jiFqD0QRMCqIZUpO6eDJ9eo= =4Cuv -----END PGP SIGNATURE----- --nextPart8094527.cgOJRtSmPS-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From hanhill2003@mentionentertainment.com Sat May 27 11:10:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk0Qm-00011U-Df for dnsext-archive@ietf.org; Sat, 27 May 2006 11:10:20 -0400 Received: from 21.red-81-44-194.dynamicip.rima-tde.net ([81.44.194.21] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fk0Qe-0000o3-3Q for dnsext-archive@ietf.org; Sat, 27 May 2006 11:10:20 -0400 Message-ID: <000001c681ca$7c92a500$0100007f@localhost> From: "Lane Taylor" To: Subject: Massive PE patch sale Date: Sat, 27 May 2006 17:09:31 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C681CA.7C92A500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C681CA.7C92A500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C681CA.7C92A500" ------=_NextPart_001_000E_01C681CA.7C92A500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a fistfuls without parting the face of press grew poseidon Black tracking mouths, the thence swallowed up the sun seaman air was unindoctrinated with suppressed related The wind audi through the long welter and sobbed and quarreled the secret honesty ------=_NextPart_001_000E_01C681CA.7C92A500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby ------=_NextPart_001_000E_01C681CA.7C92A500-- ------=_NextPart_000_0001_01C681CA.7C92A500 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C681CA.7C92A500 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhQgIDAZEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAgMBAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTlcHAyeb8VbGOXOXQBDCA/R6233TB1gReECoBsSW2AZQp9HY8mgQOTG5 UllxaWLYQbgJ4/mJEQi6Qwr2mEm5CJOK0WryChGbN9J5Y9qCyzBKpBt197eAuqp4EDdXzJic rMDsvBipCN32djxtnNi8nK3NLelt/a2NjXz9XU6+GoEHjADcx/7O124Qv9dOn8BXX1iYr/+v Xz5794K9q/fvIEKD/oLtKehuoAJ4/R7Ks+jQXcWC/xQrEhSYUSHGi/FGScwYRN6mYeKUtWTp 8qW6lthk0qwZU1pOc+ESoIuJoKdQnjN32jSKdJY/jxrvbeTllJ/Uh/qk7ptKtYEhh/M2Uu1o daLYrF/BNt36NOxSrFOvqrW6ieuCrljlkqVbRKUwnUmJpjOHNOjMnsqi+cU59CZNwogPJ/bp OPLRuQHv1r2MGWpWtF8te5079q1ns24/d2Zq+nRVdpsxs+VHOvOuplU9y0ZtRO84yOfA+Z4s rWjhv+omPV7smxnOwI17h4MGtPGzctvIDTp70TZUzWbVotQNsPJ22qrBJ7Q7/qnCuBZb2yYr 0Gvp0uThra+P/f4R8IJ3G//+SVgrjKWz12RAPeMAgEUdJ9g0wg3Y23ISRgdBerW1dRZt3Z3G Wmr4XajaaB6adpWFIdIHW3uiaaZRbCKChtuJH7KHhEi83YgMgUf9xEgDARq4Y3HE/CbJbswF aYyEhi2m44GKzWLifPK5tmGJGJJI3m1asvialTFKCV9aX2Y5JW4Mwbiiay++5csQwSHXSJzT RdiNkAruxU0deg7mDWQOPgiYcnsWSOeECBYmnAPZLeQio2W6lyGkNkYknkidSNSQfVxhytGj 2XnSKD5ksmWjqGEyahI9l3bYFqdtHgLrE682MSsZtT5wa6y67hqaFrmC8atWvA5LbLHGHots ssr/LsvsC216Oaqvwc6GAo3NXostZXatI9prvpIwrQThepttuWWYiGu3p2YxLpqaeNCuufI6 wd55KIXY6raaWrtvmR/BFpKrn63HaWf23tupo1eGx9AfbvU74rwSbxFXR1yiCKbFZGo8ZlQA dQwWZ2uW1fHGkYa5Hccykjtxy+wWDGaMaaaoZnxa4uuvhu3xe/LKXKKss7Urq6idy0aHkfGi 6sbMKn82j4xiZouyxqrOIPdc8b4hUTsz0eYdDXYXGSvaJZWQCusiujmDRjWaUd5MStREzxi0 h/GGjXcOb7+Hc8zvgUo3QuTuvfCFFp7JZtxbhob439HmDTmtMGc6lsiT/64KCuaU4kxlQBvW Ze/QplKaasjaDg1fqZGvzvq6rb8O++t3x0577bbfjnvuuu/Oe+++/w78xEoZGcPwshhv/Ayv JN87wulOMbslfCaYqGLESz8hHdUfb8Ty28cwa/QrzJ6r+DV83kNyjnxfPPvrZ8B8EPGXEH4S 5ItCBfqfVHaOdYVak6dtKKhPDRrSTvZUjWJQZ0h9Ug6i/lQTOTWJL86ZIDX41MDfJLBJD+Rg hSBCOYCVDlUYUdin+BeyyZWwRQGTi0qo1kKKxFBhKwTJCGVjEBSexHmWAiEJWWYHpSWpGhTq C5CQVMShZOM4F2yOEYu4HCVK8ImPkeL0qKhAyf8cSVwqI9nMTEItFlkOboKbyOfwAsYv8swj FbsaGyOWMiy9sWvmu4DTikTEBWoRgVVc0GGQGMU9AsZIDOoPFpEIIUQOso9HDGHgvog1YTlO LGnr2YdqI8ZIrquS7hpbyTpZM6iZzQ9CLNIhT3nKYVSHOE8yICoJiJxGpjIyq/TPnxjDyAMp JWX6gUsvU/fLO3pNk4BTj6ouWZZfWk1dZByZDx+Jsk9p0nVBnJQpc5nLWV4vOjAJpCJvZMgn 2vKbWzTOH5UkSHByS2Y3e5Qo08VJZr4zk+zc5Np65Ul5igx13iJcHe3Ivx7hKJ26JGc4F0kM Jt1JnNZbqDnJyUTrARL/oQaVqCQh6UY1+a2YW5Lb3uiJUcZZ8p7l8Sg+Q/nRtXSPkKsMEACz WUBDZZA6unQoLLlJJJYutIP/SxQFEYVODvLFgRUqlQoTthBgDiSHzlNqqjjHkdLRZ3SbKVh9 rOqp0M0noD1MTVfzdbbgucF9hPrBP98FgrOKda0oIKoqUrIfEaiVrXStq13vite86tUF8yvr +yTQV8CSdXwciBe02MUsoRHrTdQTQWAvwaMTBBag1tSA4iZgizxUtrB4U6wF5uqDyBYBsoMF wWQ/Sz+yYRZE8HpcBkB7LnfZ8Qqb5dGhgFooPzFQqAEETgCXyMDgAgpOrkwMLm+q2o/REISH /1MVwRAGLYiZEboa2uFISBdVGv7LYDzc4Q1LeJCDZRW6wXRkSUhYEoc5EqmwdVYpCzrQVjY0 UH5U6Dl9W1GI0nI4hXxer8zkzK4BjUPulO087cPOzJURk1XCDshMF1KoNpPBGfWZgaEgTMZW 8EgQculf5BuYoRZXi4bEJkEhZM2vVQ5EUdvoiuf2M9bOE5osMynfZlyyLuYTlDe2cIVbbIUM N9GJNHWOHw9VSBPHEpUx1a8i3XpRwymzucfM1L1KhDnyVkqFILWqNGH0M92kVEw+ButJtVPe A1tqa1UQ8pIHlMjsMVmb8IWpBZ3MUAoUE13pIVwYaQbEGwvNxZik8f8n+0nMZe54n80cc4Td RtuA2hTEOQLniIFD50lvEbeZJnFp93yyph2W0JF6mMnkyGKNvridh8YxHTN6ZcY9bNGNPnUZ BsXTlza5TgedjnCJu9sFOvF6txWxb3c5NSs3ZNmzXuo8qFue9ZKO0eadUeiya88ef7Wq25LU ek212dGJO80Q0RS3pUvNsJ2WWO3dKyfcPQLkTqyp8C5Fve+N73zre9/87re//926ddMgzvIr bQrkLVmDRwC427yBwC/w8FWHorUlwDUcFB7aQY4W4xXnuAcELloo2gDkBo+4jFHr3ygLouPh 9CsTTA4Jj8db5toLQSZgXnPTlpzm67TsB1P/vnJRSFpId+ZpfHuKDl3zRuk9lUlyfHrTnyJZ 4xvmdK6HLCjkClCVwSUyfUPOaV/fsqbCrnrYtf50O/2n6xvWyQbPvlqmfhfLzt7Kc58td696 d9qvfS+ulXz0Kb50yHh6O0zgfF914rnDJx67nfNMaYKWuL54lDzgI0pwOh9U825PvFYaVWqJ 71Nt9XSwgAfh9+A0fpwUYlAl/v5r5uy0gJS/fO1X7/X5NlLwbA9xLWVqUNsDKZHGhjzvJ0r0 TXNN290CvapdJ7cf972ysG8p1V0qXI1HXe2AH46RWT/577sEOoe/JYkfaH7WmzP7Le8+8F9J y95y+KeLp3zufR/+/yJebtpaE/Ad6Zll/ZRmMcZF1Jd85ad7rXd9w6VOCIh/cjZs9+cn/aN+ t3cT3UQomUd8RPJ4xydOHXhfpIVnLcd5B0h1UTZobHJyyERoozdhlOUJsJckxqd9gSJRGFhp 7uckR5d/lYZTGWiDDJWDCRV42/MjnZaAPdJ92eRpO9iD52dfwWeCFsVjGIUxtvZOS5NoCzZz vTZA68d0cOdBrcRH8dd7umWBuWVxaMhb8teGUAd2WbdTFFR8ulV0HlZ1U2dBYPhH9Id0l9Y/ cgJ2y4dU2EZ3m9JdeLc5hqgtjWNu7fZWdIVzAEeJ3CNWUFaJmaiJm8iJneiJnwg+PvcFpv/w K9MSLL5QPtfxX2rgWUpAb/gDLKJIiBgGdCcAiak4WxGjA5BYYK4ILkgjixdGL7WIViyAiygX aHoTirrYC7/4Mi40Q9p1GSdEXeK1MNK1Xez1TO81NXXnQ/tgjSRRbSgkQmwTjT+kaCKkXuSY L5X0HdvoXeEFj9AIaWEhjux4bjnzjtbobQwjjUxxMLw4A2hUNqjhZ3YHaw/2c+iBhfnEMd0m fR7DGRApkS94jSvSYBGGFxHhVQuWRj6jYFeyVahGax7DkSF1RiRFkD1GW6zWZ9M0YK/WNqwG ZjBZayIZSmXGTzvpaKfSNjo2Kk2zhWdWaO60Y2wzTJO0Gio5ONP/9JNc05N+E2TkxmVwU0r+ tDNWFn1fdnqu9pDVVWUaKXpnJmZBmZX+h5Q3SZRcOUllSTYziTr1wpTZ5ksn4TXiNpQ7CT02 6WN+xmPccZY+uXwlCU2m5h15SZitRnox9pRoSUlzyVE6CYDCGB9CqZQtApmD2ZRwaTiImZNS 4Jd9uRYgNZeFQ3peaTkOaZCemYWKOZQ8VJp0uSaNU5jPh5JQCZOR2VxN+Un6E0+O2CrS4lze WG1JZW6FqGzS1h3bxjBMo17TlY8XKTprJmrdNpEbY1QtRJfc8Zy8+W3PCSrZSZtUhY12M14s qTnM5p3RSWb4pFWdUzWsI5D7dj8TlwLz/wmKyZifq0ULzkJY+wmgASqgA0qg/3aM/2kHaYWf Bcqg9uafFMcDC9qgASqQhuUDEjqhunJe46gvOnQm3ZiIMhRDWVOedIRVGyqNYmZd4XWOKPqN CZGhvMOQc0RgKjdgBEijUhmT0cZ80aSQpumR7ZmjGAKYMao7USlPBdmepGiROypDvdg3rJmF KelMRWqkuMNLYVlS4Ql6wsSWOvqiqjNetDkaX1qaKaSlU5VsV4qlIxVgl7WcKZeYEoeZaklS nuKUEZlZq8imsIOkO/piLphqswmnoRacbyqlWCmWrYGjfeqn4rk2ldVVIMqlwGmc0zV3xnRu GAOpGnVUaGqpYf/aqI4KORjqBaZKqvqGqlywqqnqqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrOYSANEqrdNKrdVqrdeKrdmqrdvKrd3qrd8KruEq ruNKruVqrueKrumqruvKru3qru86riAAr/NKr/Vqr/eKr/mqr/vKr/3qr/7aAf8qsANLsAVr sAeLsAmrsAWbAdZqNNQ6BhD7BBJbBBS7O9XasNMKNhb7BRy7BB4bBCCbOyL7ABh7NCSrBShr BCrLAyxLOyZLAS6LLTJbBTQbshq7sjj7OzYLADD7sDoLBjz7A0JbA0S7Oj4LAUjbMkb/WwuQ yLSaxQFPGwNSizdK6wBWKzFPK0wnuQtOC7Tr8F5CF7VfC7YrWAJUGzZYywBqK1d7igVai2Cf pyheK62op1KAEC5CC6MsgLYba7Nsq1mjCgVwq1J3p4jYtlybNQE8uynf6VxlhIgI1lR6W5Ha RReveLVke7F/27fc0qGNm0PYNbSai1lxe5KNCzCQe7ntwrhxG7pR8bqve7qKS7nosbqqm7F1 CzyAmwC8+wEfgZDl5jC36wOE65EEc7ewS7yYKwGtu2a4q7zQa4i4QLmwC72x+yud+7Oku7ba +zyIc0LXu5E7ALfPG71ceL7mwbwly71da5IqKr7xa5Ldq7t6/7YUy9sh2bi47Xs7vnsA/vtu goO/4qu4NmC8yiW730G8lLEBrXu8ZiS/2Iu+C1C9TrHAw6kB3ru0nMu/aXW/EbzAQHDAs/vA qXu+wNTAHaxcJzzA6RvC9ButyMhcaPSRF6DBEwPAPXvDgynBLhykxavCctuIx4m8EkmcGRzE d5t3yTm9yYm5FXy8AcO1NpzEsJPDORx0UdzDkSvCVTwFOwzBJwDGJjDG0MrB9bu9MSwGZVzA H1DGJPDG2XLFcVwGdNwDdpwCeOzGXtw6c8zHyqLHOhDIZPzHNDDIyeLHhXwsh3wDjDwCjpy7 auw7Dru/kJyyiuwEliyvmDy1nJy2if+syVYQyp2MxkwwyjHryWl8xgvLyq3syq8My7Esy7Mc rqhMy7eMy7msy7vMy728rbbsy8EszMNMzMVszOoKzMeszMvMzM3szLKczM8szdNMzdVszeka zdeszdvMzd38zNnszeEszuNMzq8MzuWMzgYrALo8AOnszrVcyd0qD9F6B+H6Du4KDMRcz9Ka z+a6z9jazwh7zwEwz/T8z9ca0AXNrtJArWwwrYqwrRAtrQzdyipBrwc9ressrhrNsPG8rf+s 0RjtrSKdriSdywNN0Ots0iPN0QDd0gW7zyFt0DO90vUc0y+9rg4dre080TodADrt09YK1Dz9 00T9yhyN0+3/mtTCfM7WitEKjdIondIurdJIndADbdMhfdUpXdUr7a8gXdVOndX83M9QjdVX DdYBPa8mfdNTjdBhzdVLba5B/dA+PdTZetc7nQiwrNJk7dZcndFeHdf0/Ndb3dZp7dcHPdbz 2tRi3dKKrdVuDdbZms9PDdcEbdAiPdaVHdkHO9lsvdh+/deFTdNwvdiCXdJqPdNTXdOmvdo5 LdE7XdQ9rdd4zdN2XduurNaKzc+E7dtO3duSndGB7dsxPdyiLdOj/a6N7diindmcHdVyLdla zdnVutv3fNgKDdNWrdzITd1t7dyJ3dXQLd34DNmB7dVS3d3pKtG3bdQUja3wTdu6/43ZwU3W Za3e1JrQ9l3fv53c/Q3gSO3f9crcb/3ayk3S6R3Z2W3d+F3aD76wn73UDD7dxK3fYZ3gqn3R j43TqG3Z7UrUQx3b8x3RRp3bFW3d+p3i3/rfj33c9S3g/B3jMc7YHq2t3C3cIE3aB97gGL7g M+7jD17dv73d4v3WQV7hmK3jrH3Zpl3eJX3gHx7er93ZOU3iJ37ls12tuI3lEb7i/E3kAB3c NB7gYy7jL97iBG7jlC3VaG3VN53fEB7XWQ3npY3dTo7a+WrRgG3gaY3fb07dgH3WGv6u6o3Y Fp7ZF/7k4irfFD3iWP7oj66w1+3m9y3Xgy7ogw7olt7VfP8e5+xa4F+96Oea57Rc6rw86gpr 4u8ssB1O6mrevBH+6aRO6Kg+68Gc6gm76qzer5Q+rrUO6mvO68NO7MVu7Kt87Mmu7MsuzqHO 7M8O7dEezM4u7dVu7dfOytSO7dvO7d2er9ru7eFu7S+05+IOruBu7une7bmu7uiu7u8+7vDe re4u7/W+7Oye7vRu7/te7Phu7vrO7wH/zv4u7gAv8AdPzgQf7gaP8Nys8AO767r88N2u7WZt 6Z596gnr5hMv2MD+r23O4SF/434+8UW913od1JK+5SeP8nS9riW/7dS+5AaO8Sft5Kn90TDP rsY92BAe2g2e5OfK5Xmd19da9C7/r9QNX8Us/tKG/uaZXucZ3uQb7/OGTec6v9F4PuGhremA /t0X/9xYz+ZibeRM7tLTnfFGv+pE7962feIqr65iX+0VL+XhvdmdXdlHjuBN/txAT+dB3+vJ DdqXvdrnXdxIftpyf+RN3+E/fvY8n/Yrz/Js3+UN3fayreX4rPSlzL5Mz+EXTtxXD95nj/Y/ n+icXuHlzq+avfWFf9aIbuQWfevm/fmwf+tOj66xDd/yLdSSjvRQvvkB4O6TDftKzuPrbeGJ 392vb/bN3+pJDdpVH+WN7/zorfhjb/fQ/+R1P64hvvbf360u//voev3QLvPOzf2eDuQjj/h8 b/YMPuQA/67nTX/8ia78Ob7+XA/48FrlBBAp8pIVeTXzjJMXy8HGbv0CP08jTTJLVWht3ReO 5ZmGgRvPdSA+fMeHCEYmlCCQeFkQh8Jf0dKcTIuU2rVqTEqW2iMUCYR+h9jeM+t8oi2QLbvW kXPmdNFodE/IUWaM1S9QcJAwZucQp1BRCXCRyhGyYSuScqWxcrAPM/Jy0/NTEBER1Kxs8Yt0 0DR1s5NVRvM10FW21lb00FZ3l7fX9/eX1g3VcVKhRvg0OQN3B/gZOlp6mprrxahyeVr7olmn GjxcfJzcT1vI7ZENjjHCaTjd/V0syqorZW0+qsY7p/wfYECB1M4lMciiwrEM2P+o2JP0ACJE SQ8VRsSH0F1FbhL6JRr4EWRIkZTOJVQ4TB67hwxNtmTI0iVGhAvXyDwpo+ONkTt59vRp6ZoS a0NhSLzpsOLMmElvEjWaEKahnD+pVrU6sCTRpi0vMl168ilSsGMX2oSqVGrHq2vZtoW2bB0q uSrDjOmSjwmaMj/w0mpyF8lGBjl5uDV8GPEnwb0aLRZai3BiyZMpzyoX1zEYyFMrd/b8uSxo WZFFlzadOPNpM6RVt36V2lasf7Bdz2B9jdjKxsaw0A1pkPcZS8FlEQNuj7jmVVf4oNBDJ4/s 6NGl96jt6XYLJiqMJafhPaBefciSgQeVsUo8i8HvPTL/c8cDnxDw41cXQZ8QbU4E9XPkjLsd 5Cjqrr30Aqunrin48m0XfQpcSZ2+vEhpQpT60+6SvBoaj4t5cqPhOehKOGEP++qzozrrrvuj kOyG67CNCDXrkMMCI5rkngVjBMZBDuF5w6J0NFJwvSBJguM49fDxcEcQ5cPjgwDwk9LEEjmw 0pwr8olRvAhTotGLJdGBh8g28gLkwsH+c+GuLbk0EsYNdaRRNw/VYLAWIx+kSE55+BzwzjbP A07JBP9Asr8nsdxjUSrrSKG5+Sz7ziaWtJjoKEzP2oqFMV8y6iWl0kzARe6KfFNI3vxcdTc/ y3xVGilgjbM9V5ssk0DzBCEU/8E/l4yTOREbbU6TEDMI0dgZMlvluO001Uq5Dzs1iQyzKkTL j1J/fVXDejrRkVWM3gl3Tq54vFTVHIPMyFl1O4UTEjg15PXWdmkjUVgo9W1UWHxLQebQZ9H6 NjS4KgiLrFAzJURbMa+VFTBGvFzwSyKPqBVPXeZyxUZTxPuS4ht1LeVjvMgUkp6TmVOUWBTr Q9a5R0tMVlmAh4qqKZjEeoq7gxOuFGFsV1szz1G3/Wnk2f5JUZzULtZTwpM9xuxbiP8CA+OQ 02x40IzJS/oyaX9beuwVK+Ha7LTVfsbotRtA2+245U6lbbnhnhvvvOPVOxSi+f4b8PwCx+Lu wQ0/PP80xNPqR/HGHe/q8RYKj5xyvOsu6ruCMOxl8so9X/tykjDXjnO/Pz/dcla6bFZTW5dQ +XVeOkeddtVCZ5PPoBfeFD3eb7fN9NqFX/F3oGbi+VmFoaqW01dmH76z4iFhOhzpIae2+Z1/ dqp0tYoiA08crcdtfBmi7k0Yr0nZ2EKVD51Qv0jzdTRmmlGkblLVWydr4d6Rx152wftVt44W DbBhgl4k25wv0IMxGLHHToKAz8xihqX7VIlK8/sX3Z6mhpQxy059ad8uZtcx3RzIQFkQw19y NbERZg1dglIEkNLVIwrBL0EbO6Cy0BTCGA5QZH5Ilh4uaEEM0sd+KoJeCXv/FDD37MiBOXri CnuoDkMhaE47NJW9aFIjeX2KWxHMBjsaeCqaNORWsFDUsE6UQTceq41S4pfNlijALgrohbsB FBbRQSAzPa0dddpQGmboxTP26YsSa5MMPREXiV0RTMDCwhqfIz/6pciSGqQU9ALAxEcOcoqE IlcfM2TGPRkoXLMq5BPT1StbhXJcpdRi5lDmqyl+Mo0x8NcbSyApF8Asf8PzJLBc5T8BjfJg sgyjFXF1qnK1rVa5BNe6JMJFG4FSdNgcUi3FJ6735MtYwNxXvzRZM052Toc3vFFgPCih15HR hiGjxyJjCcldJemMZzJZXSiGSrEVUp9hShkUaShE/5bJj5IyY2MlFaolTnbSjrOR3iyPVJXy FYJ64Lhoa563jX+SjKKc+ChWyAaSjaqmow9VqVtOepqUrhSmVmmpaV4aU5v2ZKalqelNeapR Fi5HeDvt6VCJWg2hFhWpSe0e45TaVKeOgzCFeepUqfqLqEq1qlnVKiuuitWtfhWsjuiqV8Na VrMSbqxkPeta2cqMtHqkrXGVK0Tf6o+53jWsddXrXvnaV7/+FbCBFexgCVtYwx4WsYlV7GIZ 21jHPhaykZXsZClbWcteFrOZ1exmOdtZz34WtKEV7WhJW1rTnha1qVXtalnbWte+Fraxle1s aVtb294Wt7nV7W5521vf/jQWuMEV7nCJW1zjHhe5yVXucpnbXOc+F7rRle50qVtd614Xu9nV 7na5213vfhe84RWvcgsAADs= ------=_NextPart_000_0001_01C681CA.7C92A500-- From rdhowdoudo@floreriapetalos.com Sun May 28 05:41:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkHlc-0002aE-Tz for dnsext-archive@ietf.org; Sun, 28 May 2006 05:41:00 -0400 Received: from [58.208.3.159] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkHla-0001bl-Jh for dnsext-archive@ietf.org; Sun, 28 May 2006 05:41:00 -0400 Message-ID: <000001c68265$f9bf2800$0100007f@localhost> From: "Cody Coleman" To: Subject: cheap oem soft shipping //orldwide Date: Sun, 28 May 2006 17:41:13 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68265.F9BF2800" 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.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68265.F9BF2800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C68265.F9BF2800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C68265.F9BF2800-- From owner-namedroppers@ops.ietf.org Wed May 31 06:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNuL-0002CF-TC for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:26:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlNuK-0004TE-Gw for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:26:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNpP-000Hku-OP for namedroppers-data@psg.com; Wed, 31 May 2006 10:21:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNpO-000Hkj-Sf for namedroppers@ops.ietf.org; Wed, 31 May 2006 10:21:27 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 May 2006 11:21:26 +0100 X-IronPort-AV: i="4.05,192,1146438000"; d="scan'208"; a="3529903:sNHT31027464" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 15: recommend against the use of partially opt-out zones. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 12:21:16 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 11:21:16 AM, Serialize complete at 05/31/2006 11:21:16 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Issue: A single zone may contain NSEC3 records with the optout bit set or clear. To cope with the granularity of a per-record signal of opt-out introduces additional complexity for signing and dynamically updating such a zone while the use case for this granularity is not clear. Discussion: To cope with partially opt-out zone, a signer needs to know if an unsigned delegation is supposed to be optout or not. With regards to dynamic update, the server needs to determine whether newly added unsigned delegations are supposed to be optout or not. If the granularity is per zone, a signer can be signalled by a single command-line option, or by some meta data. When such a zone is dynamically updated, the server can determine if the added unsigned delegation is supposed to be optout or not by looking at the nsec3 at the SOA. Resolution: We haven't found a practical case where partially optout zones are preferred over fully opt-out zones. We therefor propose to add text to the draft that discourages, but not ban, the use of partially opt-out zones. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 31 06:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNuL-0002CH-Ti for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:26:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlNuK-0004T8-Gw for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:26:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNrU-000Hsq-Cm for namedroppers-data@psg.com; Wed, 31 May 2006 10:23:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNrT-000Hsa-O9 for namedroppers@ops.ietf.org; Wed, 31 May 2006 10:23:35 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 May 2006 11:23:35 +0100 X-IronPort-AV: i="4.05,192,1146438000"; d="scan'208"; a="3529920:sNHT43420280" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 16: The need for a Hash Length Field. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 12:23:25 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 11:23:25 AM, Serialize complete at 05/31/2006 11:23:25 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Issue: The length of a hash is dependend on the hash function used. SHA1 produces 160 bit values, while SHA256 produces 256 bit values. Currently, the NSEC3 rdata lacks a hash length field, which makes the length of the Next Hashed Ownername field dependend on the hash algorithm listed in the Hash Algorithm field. However, when the hash algorithm is unknown, the length of the Next Hashed Ownername field is unknown. It is then impossible to express the NSEC3 record in proper presentation format. Discussion: There are cases where the presentation format of the NSEC3 RR is needed. Since the Next Hashed Ownername field is followed by the Type Bit Maps, the length of the Next Hashed Ownername field is needed to determine where the Type Bit Maps start. Possible approaches: 1) present the NSEC3 as an unknown type (rfc 3597). Eventhough this is technically viable, it is not an optimal solution. The presentation format is typically useful for debugging. The rdata format specified in rfc 3597 is useless for debugging. Besides, this is not really an unknown type. 2) extracting he lenght of the hash value from the owner name. The owner name consists of a hash value (in base32 format), followed by the name of the zone. Hence, the hash length (in bits) is typically 5 times the length of the first label (in octets). Eventhough this is technically viable as well, it is clumsy. 3) add a hash length field to the rdata format. This is a straightforward way to determine the hash length, for the cost of one octet per NSEC3 value. Resoltion: The authors decided to add a hash length field to the NSEC3 rdata format (approach 3). The hash length field expresses the length of the hash field in octets. The authors consider this issue closed. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 31 07:13:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlOe1-0004Cs-1S for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 07:13:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlOdz-00008n-NY for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 07:13:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlObs-000LW0-AZ for namedroppers-data@psg.com; Wed, 31 May 2006 11:11:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlObr-000LVm-A1 for namedroppers@ops.ietf.org; Wed, 31 May 2006 11:11:31 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 May 2006 12:11:30 +0100 X-IronPort-AV: i="4.05,193,1146438000"; d="scan'208"; a="3530200:sNHT29725008" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 17: opt-out for delegation only is not enforcable. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 13:11:14 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 12:11:20 PM, Serialize complete at 05/31/2006 12:11:20 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Issue: The use of Optout is restricted to unsigned delegations. This restriction is inherited from the experimental Opt-In draft. Even-though the restriction is in place, it can't be enforced on the server side, i.e. there is a way to allow unsigned records other than delegations to exist in an optout span, without it ever to appear as such on the wire, by means of delegating them to unsigned subzones with the same name. Discussion: Assume the administrator of the secured zone 'example.com' wants the world to see 'www.example.com' as unsigned. He could delegate www.example.com away as an optout unsigned delegation to another server. This process can be automated without breaking any signatures. Delegation point NS records are unsigned, and there is no evidence the NS record exist if the NSEC3 duo that proves the closest provable encloser is marked as optout. This would violate the NSEC3 draft where a signer MUST NOT allow any other record than delegation point NS records to exist in an optout span. possible approaches: 1) remove the delegation only restriction Removing the delegation only restriction would send us back to the drawing table wrt NSEC3. We are currently beyond the design requirements for NSEC3. 2) Add a note to the draft. Since it poses no threat to the security model of NSEC3, a simple implementation note would do. 3) Do Nothing The lack of enforceability doesn't change the security considerations, nor the protocol on the wire. It is similar to an approach that constructs zones from material in a database, or using zone-file directives or meta-data to dynamically construct records. The server serves an unsigned delegation, the validator can check that. resolution: The authors think that approach 2 is best. Actual execution of this hack would require a significant amount of engineering, solely at the descretion of the zone owner, while it is not a threat to the security model. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 31 07:57:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPKQ-0004Ec-2y for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 07:57:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlOCB-0005uq-Jt for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:44:59 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlNu6-0004v7-QV for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 06:26:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNoe-000HjF-Ka for namedroppers-data@psg.com; Wed, 31 May 2006 10:20:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlNob-000Hiv-CE for namedroppers@ops.ietf.org; Wed, 31 May 2006 10:20:37 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 31 May 2006 11:20:35 +0100 X-IronPort-AV: i="4.05,192,1146438000"; d="scan'208"; a="3964820:sNHT27886156" To: namedroppers@ops.ietf.org Subject: NSEC3 issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 12:20:27 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 11:20:26 AM, Serialize complete at 05/31/2006 11:20:26 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 This week I'll send new issues recarding NSEC3 that came out of the workshop in Frankfurt. I'll also revisit older open issues. 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 fghhq@yahoo.co.jp Wed May 31 08:24:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPkt-0007RK-SH for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 08:24:55 -0400 Received: from [221.200.232.2] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlPkp-00076j-Ne for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 08:24:55 -0400 To: From: =?iso-2022-jp?B?ZmdoaHE=?= Subject: =?iso-2022-jp?B?GyRCJCIkSiQ/JE5Ia0wpJHI7WTFnJDckXiQ5GyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $B=P2q$$H/7!BbBh(B4$B2s8fJs9p$G$9!#(B http://bluejade.bz/vol4/ $BB(%"%]$G7h$a$k!*=P2q$$H/7!Bb0w!*(B koichiwakuwaku@yahoo.co.in From owner-namedroppers@ops.ietf.org Wed May 31 09:14:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQWj-0002AR-9J for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 09:14:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQWh-00037c-Vg for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 09:14:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlQU3-0004ny-W4 for namedroppers-data@psg.com; Wed, 31 May 2006 13:11:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlQU0-0004nV-Vq for namedroppers@ops.ietf.org; Wed, 31 May 2006 13:11:33 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 31 May 2006 14:11:32 +0100 X-IronPort-AV: i="4.05,193,1146438000"; d="scan'208"; a="3965619:sNHT27671404" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 18: signalling complete NSEC3 chains MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 15:11:21 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 02:11:22 PM, Serialize complete at 05/31/2006 02:11:22 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ISSUE: A server must use NSEC3 records from a complete chain. How does it know what parameters (salt, iterations, algorithm) to use that belong to a complete chain. discussion: A hash algorithm, salt and iterations value define a hash name space. There may be multiple hash name spaces due to different hash algorithms, salts and iterations values. There must be at least one hash name space with a complete circular chain of NSEC3 records. More than one chain of NSEC3 records may be complete. In order for an authoritative server to be able to find proper NSEC3 RRs, it MUST choose a single hash name space to use when selecting NSEC3s for a response. How does it determine the hash name space that is complete? Resolution: In the absence of any other metadata, the server does this by using the hash name space defined by the zone apex NSEC3, recognizable by the presence of the SOA bit in the type bit map. If there is more than one NSEC3 record that has the SOA bit in the type bit map, then the server may arbitrarily choose one. An NSEC3 with the SOA bit in the type bit map MUST be part of a complete chain of NSEC3s. Conversely, if there exists an incomplete chain of NSEC3 RRs within a hash name space, there MUST NOT be an NSEC3 RR with the SOA bit set for this hash name space. When adding or deleting NSEC3 records, the NSEC3 record with the SOA type bit set is the last one to be added to make the chain complete for that hash name space, and the first NSEC3 to be removed if the chain is to be removed from the zone. This language currently exists in the draft in section 5.2 and appendix C.1 (special considerations, salting). The authors will fold the appendix and section into a new section under 5. The authors consider this issue closed. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 31 10:28:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRgq-0007WI-IR for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 10:28:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSC-0007Yw-EH for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 10:13:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRFl-0007yP-3v for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 10:00:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRDu-00097y-JN for namedroppers-data@psg.com; Wed, 31 May 2006 13:58:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlRDt-00097l-Ls for namedroppers@ops.ietf.org; Wed, 31 May 2006 13:58:57 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 May 2006 14:58:56 +0100 X-IronPort-AV: i="4.05,193,1146438000"; d="scan'208"; a="3530974:sNHT31898232" In-Reply-To: To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 17: opt-out for delegation only is not enforcable. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 15:58:47 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 02:58:47 PM, Serialize complete at 05/31/2006 02:58:47 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa "Olaf M. Kolkman" wrote on 05/31/2006 03:53:28 PM: > > > > possible approaches: > > > > (...) > > > > 2) Add a note to the draft. > > > > Since it poses no threat to the security model of NSEC3, a simple > > implementation note would do. > > > > > (...) > > resolution: > > > > The authors think that approach 2 is best. Actual execution of this > > hack > > would require a significant amount of engineering, solely at the > > descretion of the zone owner, while it is not a threat to the security > > model. > > > Is "Actual execution ... threat to security" the actual note you > consider to add? If not, what is the text of the note you intend to > add? To be honest it seems like your argumentation is actually > targeted at approach 1. Apologies if I was unclear. All mistakes are mine. Without editors hat, I definitly do not want approach 1. I prefer approach 3. > To be more than honest, we had a long discussion about this during > the opt-in debate and we reached a consensus at that time. I would > therefore, from a process point of view, prefer to go for option 3. > At this moment I'd like some clarification on the text of the actual > note. Lets make approach 3 the default resolution. 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 Wed May 31 11:09:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSJy-0006j8-9B for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 11:09:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSI-0007Yw-8c for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 10:13:50 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRBI-0007ti-1G for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 09:56:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlR8w-0008cN-7I for namedroppers-data@psg.com; Wed, 31 May 2006 13:53:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.0.4.49] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlR8u-0008c5-H2 for namedroppers@ops.ietf.org; Wed, 31 May 2006 13:53:48 +0000 Received: from [10.20.30.68] (ns.ogud.com [66.92.146.160]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTP id 5840FB82B; Wed, 31 May 2006 15:53:47 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22--1022282979" Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 Issue 17: opt-out for delegation only is not enforcable. Date: Wed, 31 May 2006 15:53:28 +0200 To: Roy Arends X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--1022282979 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > possible approaches: > (...) > > 2) Add a note to the draft. > > Since it poses no threat to the security model of NSEC3, a simple > implementation note would do. > > (...) > resolution: > > The authors think that approach 2 is best. Actual execution of this > hack > would require a significant amount of engineering, solely at the > descretion of the zone owner, while it is not a threat to the security > model. Is "Actual execution ... threat to security" the actual note you consider to add? If not, what is the text of the note you intend to add? To be honest it seems like your argumentation is actually targeted at approach 1. To be more than honest, we had a long discussion about this during the opt-in debate and we reached a consensus at that time. I would therefore, from a process point of view, prefer to go for option 3. At this moment I'd like some clarification on the text of the actual note. --Olaf, having the chair hat in his hand. :-) ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-22--1022282979 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. iD8DBQFEfZ/rtN/ca3YJIocRArOeAKClOKfAa1M8D/LLcG1Exjd/Si9HzQCglS8z tPpQXhOGekMZVK5/r/bAV+A= =cHOL -----END PGP SIGNATURE----- --Apple-Mail-22--1022282979-- -- to unsubscribe send a message to namedroppers-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 May 31 11:36:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSkV-0006MP-GT for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 11:36:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSkU-00016O-7L for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 11:36:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlShC-000IN1-AN for namedroppers-data@psg.com; Wed, 31 May 2006 15:33:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlShB-000IMZ-Af for namedroppers@ops.ietf.org; Wed, 31 May 2006 15:33:17 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 May 2006 16:33:15 +0100 X-IronPort-AV: i="4.05,193,1146438000"; d="scan'208"; a="3532319:sNHT30318384" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 17:33:06 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 04:33:06 PM, Serialize complete at 05/31/2006 04:33:06 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Issue: Server behavior with regards to unknown hash algorithms Discussion: An NSEC3 capable server might, on load or during a zone transfer, encounter an NSEC3 with an unknown hash algorithm. As it is unable to determine which NSEC3 to send back in a response, the server can't fully provide the service intended. Approach 1) Refuse to load/accept the zone. Return rcode 2 on requests related to this zone. Approach 2) load/accept the zone with a warning. Return rcode 2 where the responses normally would contain NSEC3 records. This allows the server to provide service for DO=0 requests, and for DO=1 where the responses do not contain NSEC3's Approach 3) Load/accept the zone with a warning. Return rcode 2 except for qtype=axfr/ixfr. This allows the server to provide service for secondaries. This is not an exhaustive list. Resolution: Default approach has yet to be set. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 31 12:10:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTHU-00037Z-5J for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 12:10:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTHS-00048x-SZ for dnsext-archive@lists.ietf.org; Wed, 31 May 2006 12:10:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlTCG-0000hu-8H for namedroppers-data@psg.com; Wed, 31 May 2006 16:05:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlTCF-0000hY-10 for namedroppers@ops.ietf.org; Wed, 31 May 2006 16:05:23 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 31 May 2006 17:05:23 +0100 X-IronPort-AV: i="4.05,194,1146438000"; d="scan'208"; a="3967306:sNHT30804752" To: namedroppers@ops.ietf.org Subject: NSEC3 Issue 21: Signer behavior in case of hash collision. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 31 May 2006 18:05:12 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 05/31/2006 05:05:13 PM, Serialize complete at 05/31/2006 05:05:13 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Issue: Signer behavior in case of hash collision. Discussion: If there exists a name and a wildcard record where the corresponding hash values collide, an attacker can replace a positive answer with a wildcard and vice versa. Though hash functions are designed to be collision resistant, the question has been raised if signers are allowed to, or should check. Resolution: The editors will add a note to the draft that a collision resistant hash function MUST be used, and that zone-signers are allowed to detect hash collisions. The editors see this as a non-issue and regard it as closed. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: