September 2008 - EURO-Discuss

9 September 1300 UTC: Discussion on ICANN Travel Procedures and the ALAC Review
by At-Large Staff Sept. 3, 2008

Sept. 3, 2008

Dear all, You have been invited by the ALAC Chair Cheryl Langdon-Orr to join a community-wide discussion on the new ICANN travel procedures and the ALAC Review on Tuesday September 9th. The discussion will start at 1300 UTC and is scheduled to for 30 minutes. It will precede the monthly ALAC teleconference scheduled at 1330 UTC. French and Spanish interpretation will be available for this call if requested. Please get in touch with us before Friday, 1200 UTC if you would like to be on either the French or Spanish channel. If you are in a country with a toll free phone number you can use this number and the access codes to join the English, French or Spanish channel. A list of the toll free phone numbers is available on the meeting page for this meeting. https://st.icann.org/alac/index.cgi?09_september_2008 You will also find additional documents with background information on the ICANN travel procedures and the ALAC Review on this page. Regards, Nick Ashton-Hart, Matthias Langenegger, Frederic Teboul ICANN At-Large Staff email: staff(a)atlarge.icann.org

1 0

REMINDER / last call for EURALO – ALAC voting
by Wolf Ludwig Sept. 2, 2008

Sept. 2, 2008

Dear all, as far as I have noted, several of our ALSes with voting rights accomplished their voting for our two new ALAC reps. on bigpulse already (with your personal sign-in details you received from the Staff last week). I simply would like to remind all those who DIDN’T VOTE so far to do this the NEXT 24 HOURS because the deadline expires tomorrow evening and ALL ALSes should have voted by then. Thanks for your participation and regards, Wolf comunica-ch phone +41 79 204 83 87 Skype: Wolf-Ludwig www.comunica-ch.net Digitale Allemd http://blog.allmend.ch - EURALO https://st.icann.org/euralo/index.cgi?euralo_icann_at_large_europe

3 4

Re: [EURO-Discuss] ALAC-WG on DNSSEC
by Lutz Donnerhacke Sept. 2, 2008

Sept. 2, 2008

On Mon, Sep 01, 2008 at 03:24:25PM +0200, JFC Morfin wrote: > I blame no one. I just infer from your semantic (and side echoes from > ccNSO) that the actual purpose is not technical validation but > production, while production implies much more than technical validation. I like to use the existing testbed for a two week production grade test over the Cairo meeting. Consider it as a testbed, too. This does not mean, that all root servers out there got be signed in those days, but the recursive server at the meeting do the validation with the testbed servers. > >DNSSEC is one of the current activities of ICANN and therefore a current > >matter for ALAC. One might ask if DNSSEC is too urgent for AtLarge, the > >ALSes, and the users out there. Because AtLarge should guide the process, > >the ALSes should think about this subject. That's why I like to have a track > >on the summit. > > This is correct. However, my question is for the ALAC (on behalf of > the users) to decide first that DNSSEC / EDNS0 and NSEC3 is the way > to go, technically, strategically and politically wise. Yes, that should be discussed. > The role of an advisory committee is to just that, not to copy others' > positions. In the process ALAC should also come with additional DNSSEC > deployment advises about the user side and the global consistency. Ack. > For example, I raised the question at the IETF/WG-IDNABIS of the > DNSSEC + IDN + IDNccTLD datagram size. When you consider the real > status of the Internet > (http://www.caida.org/workshops/wide/0801/slides/castro-ditl_comparison.pdf) > you see that the EDNS0 proportion decreases. The reason might be simple: DNS servers does not use EDNS0 by default anymore, only when needed. And they turn off EDNS0 per server, if any error occured. I would not claim that EDNS0 support decreased. > >Of course. Unbound is sponsored by Verisign and the code was written by the > >big, bad, and ugly NSA agents. ... Sorry, please let keep us on safe grounds. > > If this is your position I leave it to you. If it is supposed to a > joke at mine, I afraid you are totally out target :-) I forgot to add an irony ascii-art, sorry. > >That's why the introduction of DNSSEC is much easier than any IPv6 rollout. > > As Euralo we have no Chinese user online. It would be interesting to > know from them. Or from Comcast. Why do you look far away? Why do you not accept experience from others? What do you expect? http://www.ipv6council.de/events/german_ipv6_summit/programme.html http://www.guug.de/veranstaltungen/ecai6-2007/abstracts.html

2 1

Re: [EURO-Discuss] ALAC-WG on DNSSEC
by Lutz Donnerhacke Sept. 1, 2008

Sept. 1, 2008

On Mon, Sep 01, 2008 at 01:59:34AM +0200, JFC Morfin wrote: > At 01:04 01/09/2008, Lutz Donnerhacke wrote: > >Please understand why the IANA >signed root is not considered as > >production ready: They do construct errors in the zone to see how > >clients in the testbed react. > > So, you mean they actually are working actively on deploying DNSSEC > without anyone being informed? Why did you not inform yourself before blaming others? http://ipv6.google.com/search?hl=de&q=ns.iana.org%2Fdnssec%2Fstatus.html > I understand now why brother Danny teases us in asking if this is not > a too urgent matter for ALAC :-) DNSSEC is one of the current activities of ICANN and therefore a current matter for ALAC. One might ask if DNSSEC is too urgent for AtLarge, the ALSes, and the users out there. Because AtLarge should guide the process, the ALSes should think about this subject. That's why I like to have a track on the summit. > >Please do not spread such FUD. Either you know that they pay for or drop > >your suggesting wordings here. > > I just read their own stuff and look at their welcome page. > http://www.unbound.net/ : About Unbound : ~~~~~~~~~~~~~ : Unbound is a validating, recursive, and caching DNS resolver. : : The C implementation of Unbound is developed and maintained by NLnet Labs. : It is based on ideas and algorithms taken from a java prototype developed by : Verisign labs, Nominet, Kirei and ep.net. : : Unbound is designed as a set of modular components, so that also DNSSEC : (secure DNS) validation and stub-resolvers (that do not run as a server, but : are linked into an application) are easily possible. : : The source code is under a BSD License. [cut download sources] : Support : ~~~~~~~ : Unbound is being maintained by NLnet Labs, a not for profit, public benefit : foundation. Problems can be reported through the bugzilla webinterface. In : the case we stop supporting the product we will announce such two years in : advance. Of course. Unbound is sponsored by Verisign and the code was written by the big, bad, and ugly NSA agents. ... Sorry, please let keep us on safe grounds. > >No. From the experience of roll out IPv6 as well as DNSSEC, I'm pretty sure, > >that DNSSEC is much much easier. You do not need to touch every device in > >the net. Only the DNS servers. > > You need to touch _every_ resolver otherwise it does not make sense, > except for merchants. We do not want they have an alibi to control us > and charge us more. We want to be protected, including from them. The > real daily danger for people's DNS are ISP name servers. Not a big > one but a real one. You only have to touch your last trustworthy DNS server for providing DNSSEC validation. The clients are usually not involved. The application software is usually not involved. You only have to touch your authoritive DNS server for providing DNSSEC. That's why the introduction of DNSSEC is much easier than any IPv6 rollout. ------------------------------------------------------------------------ I do not want to talk about my business here. I try to keep it separate. So if you do not want to read about commericial issues, please stop reading. ------------------------------------------------------------------------ > >I give them such a tool. They can pay for remote signing. But they should do > >it themself in the medium term. Those are their zones. > > Is that in some beta form? No, it's productive. > Do you have a documentation? Yes, but currently it's in German only. > How much do you charge? For DNSSEC remote signing between one and ten Euro per zone and month. This covers the managment costs, which relate mostly with the customer accounts, not the amount of zones to sign. Futhermore there are extra QoS fees for exclusive ressouce allocation: Maximum signing delay, life signing, ... Those costs are calculated to pay the some what expensive special hardware. We do not offer overbooked services. > How do the user consider this service: as something they prefer you do for > them? that their ISP should eventually provide? etc. This service is for companies, ISPs, and registrars who need to implement DNSSEC now, but need time to adapt their infrastructure, train their admins and hotline, and rewrite the tool chains. We offer them to buy time. > I do not think there is a DNSSEC business plan as such (as > explained to Danny), My explaination does contain some useful business cases even for the private user. > but if there can be some business plans already for some services, this is > a good news as it would certainly help (and hamper, because there would be > in addition a young industry to deal with in case we want upgrades). These > are certainly things important to know from you. I hope, I made my point clear enough without promoting commerical issues too much. Do you have further questions?

2 1

Re: [EURO-Discuss] ALAC-WG on DNSSEC
by Lutz Donnerhacke Sept. 1, 2008

Sept. 1, 2008

On Sat, Aug 30, 2008 at 02:30:32PM +0200, JFC Morfin wrote: > IMHO the situation today could eventually badly hurt ICANN (depending > on what ICANN wants to be). Questions are: > - is the root server system a good system or not from a user perspective. Yes, it's good. It provide a consistent view of the Internet and prevents large scale censorship by regional gouvnerments. > - is DNSSEC a good solution or not in a root/non root server system > from a user perspective. Yes, it#s good. It offers the users to secure their communication for free and prevents any DNS based censorship (even from local ISPs). > - who should be the concerned operators from a user perspective. >From the SSAC (my other hat) point of view, the current operators do a very good job and are trustworthy. >From the AtLarge point of view, I prefer a multiple signing key concept: You can trust the key holders you like. So if the DOD has one set of root keys, the company Verisign has a second, and other organisations has even other keys, no single party is able to modify the relevant entries without asking for signing all other parties. In the case of short term modifications, the missing signatures from the other parties will detect the modifications as an attack to the system. > - who is endangering the capacity of these operators to develop, why and how. A multi signing key concept vanishs the need for this question, doesn't it? > Yes. But we need to have the @large users to be aware enough of the > root of the root management situation. This is why they must have a > full command of the technical, commercial, strategic, societal and > normative interests involved. This documentation does not exist if I > am correct? There is documentation for all these issues out. If you are interested, I can compile a list, but I'm short of time at the moment. > TLDs) not the old "intlfile", now the NTIA root file (4) because the > largest part of the Internet is now using TLDs and topzone name > servers that are not in the root (China, ISPs, etc.) and if I > understand you well your 15000 users. You might confuse something. An alternative root does not mean, that they are using complete different data. My signed root is derived from the IANA files. So there is mostly no difference. > So the real question are : who is really controlling the IANA, who is > in position to control it in the coming months/years. Is DNSSEC > something of real interest or not depending the way the users use it? > What will be its political consequences on the stability and > interoperability of the Internet. How the semantic addressing and its > hundred of thousands of top zones will be impacted/impact all this. etc. Large questions which should be discussed in detail individually, but not yet ... sorry. > The US position over DNSSEC > will have the first advantage to teach DNSSEC to civil servants and > militairies. That's FUD. Please do not distribute that bullshit. DNSSEC advantage existes in Sweden, Puerto Rico, Brasil, Bulgaria, RIPE, and NLNetlabs. (My company does not count.) US is far behind. > >I fear > >that Atlarge organization is not able to offer this in the full broad sense. > > Let not confuse ALAC and the ALSes. ALS will not able to provide the full chain of documents and support. It's too specific knowlegde. > >That's part of my proposal. I'd like to see the signed root (of IANA) > >productive on the validating resolvers during the whole sumit and meeting. > > Question: what will be the situation of the topzone nameservers which > are not in the root but which are documented in through the TLD nameservers? They will not be asked anymore from the ICANN meeting place. The validation resolvers only ask a set of nameservers with hold the IANA signed zone. > >I run a signed root since more than two years in production environments > >(for ~15000 people) and one of the largest DLVs. > > You mean a signed root Down Loadable Version :-)? ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 36000 IN DNSKEY 256 3 5 BQEAAAABy8CjFJC4LKj+TE7U2h8eqQJ47GjH2JKCqf9X5Di3V8cNbTV0 aDRRbXOAILSjC2mgoLOokPp2YjaVFWYQF7ePFBgvk0rKydnF606jpFW5 3TDmG2qnLwxeFPMwMtTOxT6teGoTWm1t1jxCMWazZUt4qq0ykcgAzd7Q o7z+7gq0vZfZwf6tYMcukrYFdkQUqjh1ewpvjfrhqHpEHP3bM2I+8yzA xBby1vWUO8q9yzSZ7mpezlTyA6j3pV6iE2AAKd2q5kMdzOc8OLiywkef 5i5AswYSZZHcFdEuODQsz6MDxp2RbOwkZf87k8yajzZpgpVUgT38E/fP oAR5rEDC+K83cw== . 36000 IN DNSKEY 257 3 5 BQEAAAABu13HdYlS35tf+wtpDlwkfPhz9sCqYHMPUDXfNUt8ePPrBPQx ZvZIx7tere9mX3u1tC8Ooxr5IMQa7D2yn2ZfomVk9rF+7Rtxtlu9LmNS DcqCa7JwrJyhg3eDyQ/+2fOwb+XhVEsjoMFY09DglZSWHroKOieFw4X1 sZLvmmXczYv2yzd/uP5xIxxofh++vfQ4505oYlkymLehWXfT1lqqpszH 9d/A7GHGmgdS8uyXq5LJC+PPJjdndcas4DH/Ja24NrIvzzX8ZXNimO13 +YMnKQdDSxS3yQWztSVgcY2GwRLWM9fiCX+e351OnIhYE+FjhHdg6M71 6Jf8ZDGoBO5Qrn3HMejItFBekBo9Rf2ZYzukSbu06CfFBpX/HQuAOYfp 2/7D56cG8SRH2d0sF3KAygSwAs3XvDv/dXcKMMqKftw5nxvv50o9OOUH gIR9kGVAax90oz1ZgtygQMMTHe2QuAaLwqso19Y2jb3qHIvyi+N94rwQ DzUrnMR3RFbL8P4XF4yzrYIEXkx6U9X8myHYQxbHdZ3N4rBoBvjjACX1 Vpl7bdDnKC/bITW34xpmNRZl+3K80zx5r0t9O9Csdylgach0CCNsu1I9 ERHYk/rEdzvSOiwSDYpMB3MlgYARjjWfx8YfSp1QV4fwo3i6ZZ3yFtlY Kcw23zD5Qe/YtLQ5H+8= ;; AUTHORITY SECTION: . 72000 IN NS a.dnssec-root.iks-jena.de. . 72000 IN NS a.dnssec.thur.de. . 72000 IN NS b.dnssec-root.iks-jena.de. > Where can we get and test it? Simply do it. Documentation can be found on my companies website. Please search yourself. I'll not promote it. > > It's technically and > >operationally possible. AtLarge can show, that ICANN is able to handle the > >political issues (at least for the Cairo meeting) too. > > I am sure ALAC can handle it. > ICANN if I am correct has announced its intent to do it two years ago > in its strategic plan and has not moved upon it. My concern is that > the first thing the USG people will do will be to sign the root they > will use. They do not need ICANN for that. Then what shall Europe > and China do? That's FUD, too. The root zone is signed by IANA. I'll see this version procutive on the meeting in Cairo. That's all. > Additional remarks on the @large, ALAC + Europe + users aspects : > > 1) on the Unbound mailing list: (the DNS software by NLnet Labs, > sponsored by Nominet and Verisign): That's FUD. NLNetlab is not sponsored by Nominet nor Verisign. NLNetlab produces the leading DNSSEC software and testbeds. > "the U.S. has been dragging its > feet, but will now encourage itself and others to get on board. This > is a great opportunity for DNSSEC-by-design Unbound, which appears to > both work well as a DNSSEC resolver AND is leading the pack with > important new security features (e.g. scrubbers), that both > enterprise and users are beginning to value". IMHO this is something > we need to evaluate, confirm, document in layman words, etc. in the > best interest of the European publics and entreprises. I do not see any need for your request. US gouvnerment urges their suborgs to sign their zones. That's great. That's all. Brasil had done this two years earlier. > 2) I went on the http://DNSSEC.org to see if there is something user > oriented. I tried to the "How-to". The first sentence is "This part > deals with securing data in zone les. We describe how to generate and > manage keys, how to set up a recursive name server to validate signed > zone data and how to sign and serve zones." Hardly something people > can understand the meaning at first glance. I voluteered to provide a DNSSEC track for the summit. User oriented material has to produced for this event. Currently the documentation is most readable in the RFCs. The websites out there are wracky. > 3) from your knowledge of the DNSSEC, what is the current pertinence > of RFC 3833? Would it be interesting to update it and present it in a > more readable/practical way to users ? This RFC is obsoleted. Time has moved on.

4 6