From Marie.Zitkova at sita.aero Mon Jul 3 08:52:02 2006 From: Marie.Zitkova at sita.aero (Marie.Zitkova at sita.aero) Date: Mon, 3 Jul 2006 14:52:02 +0200 Subject: DNSSEC - sponsored TLD perspective - presentation at Marrakech ICANN meeting Message-ID: Here is my presentation. Best regards, Marie (See attached file: DNSSec-Morocco-aero.ppt) Marie Zitkova Head of .aero SITA Tel. +41 22 747 6385 http://www.sita.aero -------------- next part -------------- A non-text attachment was scrubbed... Name: DNSSec-Morocco-aero.ppt Type: application/vnd.ms-powerpoint Size: 109568 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20060703/655d790c/attachment.ppt From thierry.moreau at connotech.com Mon Jul 3 11:30:40 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Mon, 03 Jul 2006 11:30:40 -0400 Subject: [dnssec-deployment] DNSSEC - sponsored TLD perspective - presentation at Marrakech ICANN meeting In-Reply-To: References: Message-ID: <44A93820.5020405@connotech.com> Dear Ms Zitkova and dnssec-deployment: I am very enthousiastic about this presentation. (that's enthusiastic with the french character of Montr?al) Thanks a lot. It did carry a message, e.g. quoting Vint Cerf after this presentation: "I have to tell you I was so excited to see that list of applications that you are considering. That's very creative." "And for the first time I realize there may be applications that can use DNSsec in sort of the least part of the edges of the DNS, independent of whether the rest of the path to the route has been signed. This is a very, very interesting outcome. It says that we can start doing DNSsec at the edges for some useful purposes. Very, very interesting. Thank you for that." (source: http://www.icann.org/meetings/marrakech/captioning-dnssec-28jun06.htm -- real-time captioning of DNSSEC deployment workshop) I add no further comment, suggesting to the participants to enjoy the richness of this presentation. 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 at connotech.com From Ed.Lewis at neustar.biz Wed Jul 5 09:40:01 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 5 Jul 2006 09:40:01 -0400 Subject: is there a call today? Message-ID: My calendar says it is the first Wednesday of the month. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") From galvin at elistx.com Wed Jul 5 09:47:14 2006 From: galvin at elistx.com (James M Galvin) Date: Wed, 05 Jul 2006 09:47:14 -0400 Subject: meeting postponed: 5 July 2006 Message-ID: There will not be a teleconference meeting today and because of the IETF meeting next week the meeting will not be held next week either. The current plan is to have our next meeting on Wednesday, 19 July 2006, at our usual time. This is the week after the IETF meeting. Jim From bmanning at vacation.karoshi.com Sat Jul 8 11:35:37 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 8 Jul 2006 15:35:37 +0000 Subject: [Re: Applications/API meeting during IETF-66] Message-ID: <20060708153537.GA26706@vacation.karoshi.com.> so... tuesday 11jul2006 in room 513F from 0900-1130 at least a few folks will be present to talk about DNSSEC application/API issues and likely, Suresh's draft(s) --bill ----- Forwarded message from bmanning at vacation.karoshi.com ----- To: Suresh Krishnaswamy Cc: bmanning at vacation.karoshi.com Subject: Re: Applications/API meeting during IETF-66 tuesday morning - 0900-1130 is open. >On Thu, Jul 06, 2006 at 08:52:42AM -0400, Suresh Krishnaswamy >wrote: >Bill, > >Wondering if there is any time slot available in your meeting room >for holding the Applications/API discussion... > >Thanks! >Suresh ----- End forwarded message ----- From jacco at dnssec.net Thu Jul 13 00:24:37 2006 From: jacco at dnssec.net (Jacco Tunnissen) Date: Thu, 13 Jul 2006 06:24:37 +0200 Subject: DNSSEC howto/api for TLD maintainers? Message-ID: <20060713042437.GB14987@universe.dnssec.net> Today, I came across this interesting question from Mr Lucy E. Lynch on the NANOG list (June, 2006). --------------------------------------------------------------------------- http://www.merit.edu/mail.archives/nanog/msg00653.html * From: Lucy E. Lynch * Date: Wed Jun 14 11:00:55 2006 along these lines - there seem to be a huge number of smallish tools related to DNSSEC, but I don't find anything that looks like a package with a couple of tools and scripts that would be usable by a small ccTLD - recommendations and good written exercises that step a newbie through the process would be very useful - any pointers? I've already looked at: http://www.dnssec-deployment.org/ http://www.dnssec.net/software http://www.ripe.net/disi/dnssec_howto/ http://www.dnssec-tools.org/ lots of info - but a cheat sheet and some recommendations for basic tools are needed to get this deployed and used. --------------------------------------------------------------------------- As far as I can see, this question remains unanswered on the list. Perhaps there was a private reply. Since I'm interested too, I'm asking this list for more details. In the past I've also suggested that a good "DNSSEC Howto" and/or API targeted specifically at TLD maintainers would be a nice thing to have, but I'm not aware of current initiatives in this area, if any. Something like the comprehensive DNSSEC Howto from Olaf/RIPE NCC, but then written for a different audience. Such a document may also show relations with EPP, how DNSSEC technically fits into the larger DNS framework and well-known methods currently used in the Reg-Reg community, and include cases from .SE and .NL (if those parties are willing to share the info, of course). Anyone? Please let me know. Thanks, Jacco Tunnissen -- http://www.dnssec.net/ DNSSEC: DNS Security Extensions Securing the Domain Name System From suresh at tislabs.com Thu Jul 13 13:34:30 2006 From: suresh at tislabs.com (Suresh Krishnaswamy) Date: Thu, 13 Jul 2006 13:34:30 -0400 Subject: [dnssec-deployment] DNSSEC howto/api for TLD maintainers? In-Reply-To: References: Message-ID: On Jul 13, 2006, at 12:24 AM, Jacco Tunnissen wrote: > Today, I came across this interesting question from Mr Lucy E. > Lynch on the > NANOG list (June, 2006). > > > ---------------------------------------------------------------------- > ----- > > http://www.merit.edu/mail.archives/nanog/msg00653.html > > * From: Lucy E. Lynch > * Date: Wed Jun 14 11:00:55 2006 > > along these lines - there seem to be a huge number of smallish tools > related to DNSSEC, but I don't find anything that looks like a > package > with a couple of tools and scripts that would be usable by a > small ccTLD - > Jacco, We are hopeful of getting to this point soon. A list of some of the tools available for DNSSEC is present at the DNSSEC Deployment website: http://www.dnssec-deployment.org/tracker/ The list is currently organized according to different 'roles' relevant to DNSSEC operations -- from the perspective of a ccTLD operator the roles of name server administrator, zone data administrator and zone contact are pertinent, I think. The hope is to enhance the above list by presenting it in a form that relates to different 'adopter scenarios' (the ccTLDs would be an example of an adopter scenario as would operations such as DNS Service Providers, enterprises etc.) so that it then becomes easy to see how a particular tool may be used in a given environment. Step-by- Step guides for these would follow, presumably. It may be a couple of months before these changes begin to appear on the deployment website, but hopefully the current list of pieces from the link above will help you fill some of the missing pieces in the short term. Suresh P.S. For other folks on the list, I'm also looking to grow the list at http://www.dnssec-deployment.org/tracker/ so that it reflects the current breadth of tools available in the DNSSEC space. Pointers to tools that don't show up here are much appreciated! From galvin at elistx.com Mon Jul 17 15:37:34 2006 From: galvin at elistx.com (James M Galvin) Date: Mon, 17 Jul 2006 15:37:34 -0400 Subject: meeting announcement: 19 July 2006 Message-ID: <11D821E5F2BEB6359686776D@[10.0.0.6]> We will have a DNSSEC deployment working group plenary meeting on Wednesday, 19 July 2006, at the usual time, 1900 UTC. For the agenda we have invited many TLDs to join us and tell us about their plans to deploy and operate DNSSEC. Quite a few have already confirmed their participation. I am still confirming logistics and will send out another announcement with complete information later today or early tomorrow. Jim From galvin at elistx.com Tue Jul 18 22:49:02 2006 From: galvin at elistx.com (James M Galvin) Date: Tue, 18 Jul 2006 22:49:02 -0400 Subject: [dnssec-deployment] meeting announcement: 19 July 2006 In-Reply-To: References: Message-ID: <09A071257667804DAFE80A47@[10.0.0.6]> This meeting will be held at the usual time of: 1200 Los Angeles, San Francisco 1200 Phoenix 1300 Salt Lake City 1500 Washington 1900 UTC 2000 London 2100 Netherlands 2200 Israel 0400 Tokyo (the next day) 0500 Melbourne (the next day) The usual teleconference logistics are as follows. These do not change. You will hear music until the moderator joins. USA Toll Free Number: +1 888-221-7341 USA Toll Number: +1 973-935-2305 Passcode: 599786 Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. If your phone does not have a mute capability you can use "*6" to mute and unmute your connection. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * DNSSEC Deployment Around the World We have a number of confirmed participants from TLDs from around the world who will be present to talk about their plans to deploy DNSSEC. Confirmed participants include the following. .CI .COM and .Net .KE .ORG .SN .TH .UK From ses at ll.mit.edu Tue Jul 25 16:06:05 2006 From: ses at ll.mit.edu (Stuart E. Schechter) Date: Tue, 25 Jul 2006 16:06:05 -0400 Subject: Recent paper and upcoming workshop Message-ID: DNSSEC deployment team members: I was encouraged to share with you that Andy Ozment and I recently presented a paper titled "Bootstrapping the Adoption of Internet Security Protocols", which covered adoption issues surrounding DNSSEC, at the Workshop on the Economics of Information Security (WEIS). You can find a copy of the paper at: http://weis2006.econinfosec.org/docs/46.pdf Secondly, I wanted to let you all know that there is an upcoming workshop on the Economics of Security the Information Infrastructure. Papers on business or economic issues surrounding DNSSEC would certainly be welcomed. The deadline for submissions is August 6. The workshop itself takes place October 23 & 24. You can find the call for papers at: http://wesii.econinfosec.org/ Cheers Stuart Schechter MIT Lincoln Laboratory From galvin at elistx.com Mon Jul 31 21:35:47 2006 From: galvin at elistx.com (James M Galvin) Date: Mon, 31 Jul 2006 21:35:47 -0400 Subject: DATE CHANGE: meeting announcement: 9 August 2006 Message-ID: THIS MEETING IS BEING POSTPONED ONE WEEK to Wednesday, 9 August 2006, but otherwise held at the usual time of: 1200 Los Angeles, San Francisco 1200 Phoenix 1300 Salt Lake City 1500 Washington 1900 UTC 2000 London 2100 Netherlands 2200 Israel 0400 Tokyo (the next day) 0500 Melbourne (the next day) The usual teleconference logistics are as follows. These do not change. You will hear music until the moderator joins. USA Toll Free Number: +1 888-221-7341 USA Toll Number: +1 973-935-2305 Passcode: 599786 Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. If your phone does not have a mute capability you can use "*6" to mute and unmute your connection. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * DNSSEC Performance The objective is to gather what is known and what is not known, to encourage useful characterization of the performance data, and to identify what is missing. We would like people who have data or models to share them with the group. Let us know if you want to make a short presentation during the call, and please send any papers, slides, descriptions, etc. in advance. To stimulate this discussion, Steve Crocker offers the following. Here's my very simplistic and rough understanding of the current knowledge of DNSSEC performance. Please take this as a strawman and possible template, to be replaced with more accurate and defensible numbers. On the SERVER SIDE, serving a fully signed zone... ... uses 3 to 5 times as much memory as the unsigned zone, ... uses about 2 times as much communication bandwidth, and ... uses a small amount of extra CPU time, i.e. no more than 10% additional These numbers are broad rules of thumb, and it is obviously possible to construct situations which are significantly worse, but these numbers are likely to apply to the large number of situations. When NSEC3 with opt-in (opt-out) is implemented, the memory usage and bandwidth usage will be greater only for the signed children. If only a tiny percentage of the queries are for signed children, then these figures melt away to nearly nothing. On the RESOLVER SIDE, checking signed responses... ... requires 3 to 5 times as much extra memory to hold keying information in the cache, ... requires 2 times as much bandwidth to receive the signed queries, and takes ... requires ??? much extra CPU time to check signatures. The formulation above includes both a model and specific figures. Is the model correct? That is, does it make sense to characterize the performance increases in this fashion? Do we also want to add a section for applications in order to put the performance issue in context? That is, even though it may take extra CPU and bandwidth to check a signature chain, if the overall time spent processing DNS queries is relatively small, the impact on a user of a web browser might be relatively small. And, even if the model is correct, what do we know about the actual figures? For example, is "3 to 5 times as much memory" an accurate figure? Finally, and definitely not least in importance, what don't we know and what work is needed to gather the right information.