Re: [EURO-Discuss] ALAC-WG on DNSSEC
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.
Hi Lutz, thanks (to Jefsey and Patrick as well) for your repeated and detailed inputs on DNSSEC! Lutz Donnerhacke wrote Sat, 30 Aug 2008 23:57: (...)
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.
This is noted. We count on your special expertise in the Content Sub-WG for the Summit. A Workshop (at least) on this issue should be foreseen. I don't know whether you are already subscribed to the Summit-WG, in case not, you should do it. Thanks 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
Lutz Donnerhacke wrote:
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.
Indeed, this is the way to go.
I run a signed root since more than two years in production environments (for ~15000 people) and one of the largest DLVs.
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.
Signing the root zone on your own does not add any value to the process. OK, you trust yourself. Most people do trust themselves. Most people usually do not trust others, unless they are given a good reason to. The real challenge is to have the root signed by some entity(ies) that inspire trust to everyone. This is a layer 9 issue.
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.
The root zone on ns.iana.org has indeed been signed. But as David Conrad explained, it is a test, not meant for production.
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.
Unbound was developed based on Java prototype sponsored by Verisign, Nominet and others. NLNet Labs did the C implementation. So, if it may be correct that VRSN and Nominet do not directly fund NLNet Labs, at least they suggested to develop and alternative to Bind. While I am generally the first to bash VSRN, I must say that I am forever thankful to them for this.
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.
DNSSEC suffers the same issue as IPv6 that prevents wide deployment. We cannot just assume that the overworked sysadmin in your average SME is ready to go through hundreds of pages of technical documents. Give him a simple GUI in Windows/Linux/Solaris/whatever. Key generation, rollover, etc is just something the user should not have to worry about. A single checkbox should be enough. -- Patrick Vande Walle Check my blog: http://patrick.vande-walle.eu
On Sun, Aug 31, 2008 at 05:52:13PM +0200, Patrick Vande Walle wrote:
Lutz Donnerhacke wrote:
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.
Signing the root zone on your own does not add any value to the process.
You looked for a way to try it out and test it. If you do not like my offer, please do sign you own root. But do not talk about trustworthiness. You do not need to implement it in production enviroments, like I do. You can simply test without trusting me.
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.
The root zone on ns.iana.org has indeed been signed. But as David Conrad explained, it is a test, not meant for production.
That's why I set up my own signed root. 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. It's easy for them to not break the zone for the two weeks of an ICANN meeting incl. the summit. So they are able to provide the necessary stability for the meeting. And I like to use their work.
That's FUD. NLNetlab is not sponsored by Nominet nor Verisign. NLNetlab produces the leading DNSSEC software and testbeds.
Unbound was developed based on Java prototype sponsored by Verisign, Nominet and others. NLNet Labs did the C implementation.
It's a rewrite from scratch.
So, if it may be correct that VRSN and Nominet do not directly fund NLNet Labs,
Please do not spread such FUD. Either you know that they pay for or drop your suggesting wordings here.
at least they suggested to develop and alternative to Bind.
Do your really claim, that suggesting a thing does include to sponsor the implementor? I can't believe it.
While I am generally the first to bash VSRN, I must say that I am forever thankful to them for this.
Please stay away from your US centric view. Verisign did provide a testbed for NSEC3. That does not mean, that they are the sole inventor of everything.
DNSSEC suffers the same issue as IPv6 that prevents wide deployment.
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.
We cannot just assume that the overworked sysadmin in your average SME is ready to go through hundreds of pages of technical documents. Give him a simple GUI in Windows/Linux/Solaris/whatever. Key generation, rollover, etc is just something the user should not have to worry about. A single checkbox should be enough.
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.
At 01:04 01/09/2008, Lutz Donnerhacke wrote:
On Sun, Aug 31, 2008 at 05:52:13PM +0200, Patrick Vande Walle wrote:
The root zone on ns.iana.org has indeed been signed. But as David Conrad explained, it is a test, not meant for production.
That's why I set up my own signed root. 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. It's easy for them to not break the zone for the two weeks of an ICANN meeting incl. the summit. So they are able to provide the necessary stability for the meeting. And I like to use their work.
So, you mean they actually are working actively on deploying DNSSEC without anyone being informed? I understand now why brother Danny teases us in asking if this is not a too urgent matter for ALAC :-)
So, if it may be correct that VRSN and Nominet do not directly fund NLNet Labs,
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/
DNSSEC suffers the same issue as IPv6 that prevents wide deployment. 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.
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? Do you have a documentation? How much do you charge? How do the user consider this service: as something they prefer you do for them? that their ISP should eventually provide? etc. I do not think there is a DNSSEC business plan as such (as explained to Danny), 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. jfc
Lutz Donnerhacke wrote:
While I am generally the first to bash VSRN, I must say that I am forever thankful to them for this.
Please stay away from your US centric view. Verisign did provide a testbed for NSEC3. That does not mean, that they are the sole inventor of everything. BTW, Most of my wording came from the NLNet Labs press release. There was some irony in my original sentence. Being sometimes considered by the Americans as an EU undercover agent, I find it refreshing to be called US centric.
Jokes aside, it is healthy to have another DNS resolver which does not use the Bind code and is under active development. I do use Unbound in production and as you may know, I have contributed some input for its binary packaging in Linux distributions.
DNSSEC suffers the same issue as IPv6 that prevents wide deployment.
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.
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.
Until such tool is included as a standard feature in mainstream OSes and/or registrar web interfaces, I am afraid DNSSEC will not reach critical mass. This is where I think ALAC can help, it the sense it is well placed to talk to registrars to get it included in their range of off-the-shelf services. Ditto for IPv6 glue records. -- Patrick Vande Walle Check my blog: http://patrick.vande-walle.eu
On Mon, Sep 01, 2008 at 08:01:35AM +0200, Patrick Vande Walle wrote:
There was some irony in my original sentence.
Sorry, my fault to miss this last night.
Jokes aside, it is healthy to have another DNS resolver which does not use the Bind code and is under active development. I do use Unbound in production and as you may know, I have contributed some input for its binary packaging in Linux distributions.
Ack, that's the point.
Until such tool is included as a standard feature in mainstream OSes and/or registrar web interfaces, I am afraid DNSSEC will not reach critical mass.
dnssec-signzone is included in the standard distributions. rollerd etc. too.
This is where I think ALAC can help, it the sense it is well placed to talk to registrars to get it included in their range of off-the-shelf services. Ditto for IPv6 glue records.
Yes, ALAC can keep an eye on registry contracts to enforce DS and v6 glue in the TLDs. AtLarge can produce a strong pressure to the registrars to offer such services.
participants (4)
-
JFC Morfin -
Lutz Donnerhacke -
Patrick Vande Walle -
Wolf Ludwig