So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh. Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond. I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take. Over to you....
* Jim Reid:
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list.
I asked them a procedural question about the comment process and haven't received a reply. Maybe non-citizens aren't eligible to comment. 8-/ -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Oct 15, 2008, at 2:17 AM, Florian Weimer wrote:
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list.
I asked them a procedural question about the comment process and haven't received a reply. Maybe non-citizens aren't eligible to comment. 8-/
As far as I am aware, anyone and everyone is eligible to comment. You just have to follow the submission rules (otherwise your input will likely be ignored). You will note on http://www.ntia.doc.gov/DNS/DNSSEC.html that as of today, 8 people have submitted comments. Given the international nature of this particular situation, I personally think it particularly important that folks outside the US provide _substantive_ input (that is "<aol>me too!</aol> is likely not helpful) on this particular topic. Regards, -drc
At 7:10 -0700 10/15/08, David Conrad wrote:
(that is "<aol>me too!</aol> is likely not helpful)
Amen, brother. Folks getting these replies do know when they are subject to "ballot box stuffing" when they are trying to gather ideas. One brilliant answer clobbers a thousand "me too's" to one other opinion. This is why I think energy on this is better spent replying to the NTIA than here. 'Course, a discussion here might help folks prepare responses to the NoI, but, the discussion here won't be considered by the NTIA. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
On Wed, Oct 15, 2008 at 10:44:34AM -0400, Edward Lewis <Ed.Lewis@neustar.biz> wrote a message of 18 lines which said:
This is why I think energy on this is better spent replying to the NTIA than here.
If you want to spend energy on DNSSEC deployment, you can also sign your zones, add them to a DLV registry such as the ISC one (*) and enable validation on your resolvers (and then handling your users's complaints). It will probably have a stronger effect than carefully crafting a reply which will probably be ignored, as all input from outside the US has been ignored in all forums since the take-over of the root. PS: thanks to the managers of ".br" and ".cz", the two first TLDs to appear in the ISC DLV registry. (*) Even if the root is signed, some TLD won't be signed overnight. Two good things about DLV is that it does not require the root to be signed and it does allow managers of SLD to be attached to a chain of trust even if their TLD is not signed.
On Tue, 21 Oct 2008, Stephane Bortzmeyer wrote:
On Wed, Oct 15, 2008 at 10:44:34AM -0400, Edward Lewis <Ed.Lewis@neustar.biz> wrote a message of 18 lines which said:
This is why I think energy on this is better spent replying to the NTIA than here.
[...] It will probably have a stronger effect than carefully crafting a reply which will probably be ignored, as all input from outside the US has been ignored in all forums since the take-over of the root.
I would not underestimate the effect of a thoughtful reply to the NoI. Since VeriSign interacts with the US DoC surrounding root zone maintenance, I know the staff there. They are clueful and I believe they want to do the right thing. I also believe that the NoI is a genuine request for information and not some kind of bureaucratic formality. Matt
On Tue, 21 Oct 2008, Stephane Bortzmeyer wrote:
PS: thanks to the managers of ".br" and ".cz", the two first TLDs to appear in the ISC DLV registry.
Why should these be in the DLV ? I'd rather see people configure their resolvers properly. Will this cause people who use properly configured resolvers to send DLV requests for those TLD's? Paul
On Tue, Oct 21, 2008 at 10:59:46AM -0400, Paul Wouters wrote:
On Tue, 21 Oct 2008, Stephane Bortzmeyer wrote:
PS: thanks to the managers of ".br" and ".cz", the two first TLDs to appear in the ISC DLV registry.
Why should these be in the DLV ? I'd rather see people configure their resolvers properly. Will this cause people who use properly configured resolvers to send DLV requests for those TLD's?
Paul
they should be in the DLV so that ISC can properly bid for being the root key operator. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
* Bill Manning wrote:
they should be in the DLV so that ISC can properly bid for being the root key operator.
Using this argument, I will control a root key, too. . DNSKEY 257 3 5 ( BQEAAAABu13HdYlS35tf+wtpDlwkfPhz9sCqYHMPUDXf NUt8ePPrBPQxZvZIx7tere9mX3u1tC8Ooxr5IMQa7D2y n2ZfomVk9rF+7Rtxtlu9LmNSDcqCa7JwrJyhg3eDyQ/+ 2fOwb+XhVEsjoMFY09DglZSWHroKOieFw4X1sZLvmmXc zYv2yzd/uP5xIxxofh++vfQ4505oYlkymLehWXfT1lqq pszH9d/A7GHGmgdS8uyXq5LJC+PPJjdndcas4DH/Ja24 NrIvzzX8ZXNimO13+YMnKQdDSxS3yQWztSVgcY2GwRLW M9fiCX+e351OnIhYE+FjhHdg6M716Jf8ZDGoBO5Qrn3H MejItFBekBo9Rf2ZYzukSbu06CfFBpX/HQuAOYfp2/7D 56cG8SRH2d0sF3KAygSwAs3XvDv/dXcKMMqKftw5nxvv 50o9OOUHgIR9kGVAax90oz1ZgtygQMMTHe2QuAaLwqso 19Y2jb3qHIvyi+N94rwQDzUrnMR3RFbL8P4XF4yzrYIE Xkx6U9X8myHYQxbHdZ3N4rBoBvjjACX1Vpl7bdDnKC/b ITW34xpmNRZl+3K80zx5r0t9O9Csdylgach0CCNsu1I9 ERHYk/rEdzvSOiwSDYpMB3MlgYARjjWfx8YfSp1QV4fw o3i6ZZ3yFtlYKcw23zD5Qe/YtLQ5H+8= ) ; key id = 47484
On Tue, Oct 21, 2008 at 10:59:46AM -0400, Paul Wouters <paul@xelerance.com> wrote a message of 10 lines which said:
Why should these be in the DLV ?
Because, otherwise, how could I validate domains under ".br" and ".cz"? By trying to find a public key on their (https) Web site and adding it as a trust anchor? By exchanging PGP-signed email with Federico or Ondrej? This does not scale.
I'd rather see people configure their resolvers properly.
What is a proper configuration? My BIND has: dnssec-enable yes; dnssec-lookaside . trust-anchor dlv.isc.org.; dnssec-validation yes; include "/etc/bind/trust-anchors"; // A few DNSKEY for domains // I was able to check personnally Better suggestions are welcome.
Will this cause people who use properly configured resolvers to send DLV requests for those TLD's?
If "properly configured" is the configuration above, yes :-)
Stephane, On Oct 23, 2008, at 2:16 AM, Stephane Bortzmeyer wrote:
Why should these be in the DLV ? Because, otherwise, how could I validate domains under ".br" and ".cz"?
IANA is planning on announcing the beta version of the IANA interim trust anchor repository during the upcoming RIPE meeting. This TAR uses the established trust relationships to obtain the trust anchors and publishes those trust anchors via an X.509 protected web site.
This does not scale.
True, however it does scale for TLDs.
What is a proper configuration? My BIND has:
dnssec-enable yes; dnssec-lookaside . trust-anchor dlv.isc.org.; dnssec-validation yes;
I've always been curious why there are two binary switches for turning on DNSSEC in BIND (particularly since BIND always sets "DNSSEC OK", regardless of whether those switches are true or any trust anchors have been configured), but that's not your issue...
include "/etc/bind/trust-anchors"; // A few DNSKEY for domains // I was able to check personnally
Better suggestions are welcome.
FWIW, on my laptop, I have a really simple cronjob that fetches the root zone trust anchor from IANA's testbed and HUPs the server. However, I won't actually care about the ITAR itself, since I slave the root zone on my laptop and the IANA DNSSEC testbed root zone has all the TLD trust anchors to date and will continue to do so. The ITAR could, of course be fetched instead of the root zone trust anchor if you don't happen to trust IANA's generation of the root zone in its DNSSEC testbed. Regards, -drc
David, On Thu, 2008-10-23 at 09:14 -0700, David Conrad wrote:
This does not scale.
True, however it does scale for TLDs.
I disagree, for my own (admittedly lazy) sysadmin standards. Right now, one needs: * SE keys, pulled from their WWW site, plus you need to subscribe to a mailing list to get announcements about key rollovers. * RIPE keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list; which is the same as the SE list now thankfully. (Okay, RIPE is not a TLD, but I consider the DNSSEC-secured reverse tree to be at an equivalent level.) * BR keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list. * PR keys, pulled from their WWW site (not SSL secured, but oh well). There is a link for a mailing list, but the page wasn't working when I tried (reported, surely just a temporary error). * CZ keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list. * BG keys, pulled from... the Unbound setup? (Sorry, I could not find they trust anchor information online, nor a mailing list. Possibly only in Bulgarian?) At least, this is how I think one has to do this "properly" (instead of just looking for keys in the TLD servers). This is already a lot of work, really. If you use DLV, you can remove the work for BR and CZ from this list (and hopefully more soon), *plus* get a lot of records for unsigned TLDs.
FWIW, on my laptop, I have a really simple cronjob that fetches the root zone trust anchor from IANA's testbed and HUPs the server. However, I won't actually care about the ITAR itself, since I slave the root zone on my laptop and the IANA DNSSEC testbed root zone has all the TLD trust anchors to date and will continue to do so. The ITAR could, of course be fetched instead of the root zone trust anchor if you don't happen to trust IANA's generation of the root zone in its DNSSEC testbed.
Nice! At least for the TLD space. :) -- Shane
Shane, On Oct 23, 2008, at 12:23 PM, Shane Kerr wrote:
David,
On Thu, 2008-10-23 at 09:14 -0700, David Conrad wrote:
This does not scale. True, however it does scale for TLDs. I disagree, for my own (admittedly lazy) sysadmin standards.
Apologies, I elided a bit much. I was saying the ITAR scales for TLDs. It can be argued that it most likely won't scale as a general (that is, more than TLDs) TAR since, if nothing else, I suspect caching server implementations probably aren't built to handle O(100000+) trust anchors.
If you use DLV,
I've resolved (pun intended) to not comment on DLV. Regards, -drc
On Thu, Oct 23, 2008 at 09:14:04AM -0700, David Conrad <drc@virtualized.org> wrote a message of 44 lines which said:
IANA is planning on announcing the beta version of the IANA interim trust anchor repository during the upcoming RIPE meeting.
ITAR won't replace DLV because (correct me if I'm wrong), it will work only for TLDs. Many TLD won't be signed overnight (signing ".com" is not something to do lightly, ".fr" is not signed and has no detailed plan for DNSSEC yet, ".de" announced nothing, etc) so, EVEN IF THE ROOT IS SIGNED, we still need DLV. I manage sources.org. Without DLV, I would need signature of the root AND of ".org" AND cooperation from my registrar (which still does not allow AAAA glue, I wonder how long it will take them for allowing DS). With DLV, it works for every one who is too lazy, like Shane, to try to find the public key of my small vanity domain in a secure way.
Stephane, On Oct 24, 2008, at 7:03 AM, Stephane Bortzmeyer wrote:
IANA is planning on announcing the beta version of the IANA interim trust anchor repository during the upcoming RIPE meeting. ITAR won't replace DLV because (correct me if I'm wrong), it will work only for TLDs.
It is true that IANA's iTAR will only accept trust information for TLDs. If the Internet community wants the IANA to support a more generalized TAR, I would think the normal course of action would be for DNSOP to put out an RFC with an IANA considerations section telling IANA what to do.
EVEN IF THE ROOT IS SIGNED, we still need DLV.
I would agree that we will likely need some mechanism to distribute trust anchors for the various islands of trust that will continue to exist even after the root is signed. I will not go so far as to say we need DLV which I personally believe is non-scalable, non-standard, and imputes a highly questionable trust model into _every_ non-cached DNS lookup (sigh, another broken resolution).
I manage sources.org. Without DLV, I would need signature of the root AND of ".org"
As you may be aware, PIR has already announced they're planning on signing .ORG. Based on empirical evidence, I suspect .ORG will be signed (and in the iTAR) before the root is signed.
AND cooperation from my registrar (which still does not allow AAAA glue, I wonder how long it will take them for allowing DS).
You might want to consider changing registrars. Regards, -drc
David Conrad wrote:
DLV which I personally believe is non-scalable, non-standard, and imputes a highly questionable trust model into _every_ non-cached DNS lookup
bingo. as i said when it was proposed, dlv is just isc ego producing root envy.
my registrar (which still does not allow AAAA glue, I wonder how long it will take them for allowing DS). You might want to consider changing registrars.
as you likely know, the problem is opensrs, which is behind all the low-cost and open registrars. and we don't want to change to less open ones. randy
On Sat, 25 Oct 2008, Randy Bush wrote:
DLV which I personally believe is non-scalable, non-standard, and imputes a highly questionable trust model into _every_ non-cached DNS lookup
bingo. as i said when it was proposed, dlv is just isc ego producing root envy.
Interesting conclusion. See, the way I understood it from Paul, is that it was not *meant* to scale, as it was an interim solution until not only the root, but large zones as .com got signed properly. You're claiming that isc had both bad intensions and bad code. I think I'll use Ocam's Razor here, and stick with Paul's explanation.
as you likely know, the problem is opensrs, which is behind all the low-cost and open registrars. and we don't want to change to less open ones.
I'll see about getting an update on that situation for you. Paul
bingo. as i said when it was proposed, dlv is just isc ego producing root envy. Interesting conclusion. See, the way I understood it from Paul, is that it was not *meant* to scale, as it was an interim solution until not only the root, but large zones as .com got signed properly.
You're claiming that isc had both bad intensions and bad code.
no. bad security model allowed by ego. randy
On Sat, Oct 25, 2008 at 01:53:48PM -0400, Paul Wouters wrote:
Interesting conclusion. See, the way I understood it from Paul, is that it was not *meant* to scale, as it was an interim solution until not only the root, but large zones as .com got signed properly.
Paul
this is one of theproblems I have w/ DLV. Either its useful until the entire tree is signed/linked or there is some undefined threshhold where its "good enough" and the operator castrates all the small fry who were depending on it working. it was never clear when/where the threashold was for DLV, just that when in ISC judgement, things were "good enough" they would turn it off. which argues for caching your security tokens in multiple places, esp when you may not have a business relationship w/ the key holder. Of course ISC could turn DLV into a profit center by charging for key mgmt. (profit might be a poor term - how about cost recovery?) end of the day, the trust chain ends @ ISC not IANA. This might not be a bad thing. Trading one not-for-profit California corporation for another one... but is that -really- what the Internet wants? --bill
On Oct 25, 2008, at 10:53 AM, Paul Wouters wrote:
You're claiming that isc had both bad intensions and bad code.
This is NOT what I am claiming. I stated: "[...] I personally believe [DLV] is non-scalable, non-standard, and imputes a highly questionable trust model into _every_ non-cached DNS lookup [...]." If you believe any of these are incorrect, then you do not understand how DLV works. This says nothing of ISC's (or Paul's) intentions (which I do not believe are bad) or ISC's code (of which I have no opinion since I haven't looked at it). Regards, -drc
From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of David Conrad Sent: den 25 oktober 2008 20:50 (...) This is NOT what I am claiming. I stated:
"[...] I personally believe [DLV] is non-scalable, non-standard, and imputes a highly questionable trust model into _every_ non-cached DNS lookup [...]."
Configuring the resolver (caching nameserver) with a DLV also makes it as dependent on the DLV zone as it is on the root zone. If the DLV zone is unavailable, no DNSsec checking and validation will work and the server will consider all DNS data as untrusted, i.e. returning all queries with SERVFAIL. We run DNSsec validation for some 1.5 million customers with .SE as the sole trust anchor. I will leave the DLV's out for many reasons. Mats ------------------------------------------ Mats Dufberg TeliaSonera BBS P&P VAS/Internet +46-70-2582588 mats.dufberg@teliasonera.com ------------------------------------------
On Sat, Oct 25, 2008 at 09:37:01AM -0700, David Conrad wrote:
It is true that IANA's iTAR will only accept trust information for TLDs. If the Internet community wants the IANA to support a more generalized TAR, I would think the normal course of action would be for DNSOP to put out an RFC with an IANA considerations section telling IANA what to do.
do you think that "telling IANA what to do" in an IANA considerations section would be covered by RFC 2860 in this case? -Peter
Peter, On Oct 26, 2008, at 6:35 AM, Peter Koch wrote:
do you think that "telling IANA what to do" in an IANA considerations section would be covered by RFC 2860 in this case?
Why wouldn't it? Regards, -drc
At 11:17 +0200 10/15/08, Florian Weimer wrote:
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list.
I don't know that a discussion here will do more than just be an exchange amongst us chickens. Unless the WG is trying to send an organized, coordinated message, comments are better directed at the address mentioned in the NoI.
I asked them a procedural question about the comment process and haven't received a reply. Maybe non-citizens aren't eligible to comment. 8-/
Perhaps if you asked the question here, one of us may know the answer. The procedure is quite simple. Remember, they are just asking questions here, not making decisions, determinations, rulings, etc. A "NoI" is a Notice of Inquiry. They do have quite an extensive list of questions in place - a help towards knowing how to address this, but they don't "require" any respondent to address them. (Looking at other comments - where does it sound like you need to be a US citizen? Anyone can send postal mail/fax/email.) Here is what they are asking (for): The Department seeks comments on DNSSEC deployment and a signed root generally, as well as specific details, comments, and evaluations of the various process flow models proposed or other process flow models that may otherwise be technically feasible to implement DNSSEC at the root zone level. Please include... Here is where to send your comments: Written comments may be submitted by mail to Fiona Alexander, Associate Administrator, Office of International Affairs, National Telecommunications and Information Administration, U.S. Department of Commerce, 1401 Constitution Avenue, N.W., Room 4701, Washington, DC 20230. Written comments may also be sent by facsimile to (202) 482-1865 or electronically via electronic mail to DNSSEC@ntia.doc.gov. And here is the "deadline:" Comments are due on November 24, 2008 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
On Oct 15, 2008, at 15:41, Edward Lewis wrote:
I don't know that a discussion here will do more than just be an exchange amongst us chickens. Unless the WG is trying to send an organized, coordinated message, comments are better directed at the address mentioned in the NoI.
Ed, thanks for the comments and for correcting some potential misunderstandings. I had hoped the intention of a discussion here was already clear. Oh well. So here it is again: IMO the WG has an implicit obligation to make some sort of "official" response to the NTIA. [After all, it could be argued that the Tallinn "sign the root" declaration helped get ICANN and NTIA to where they are today.] So I would like the WG to discuss the various proposals in the NTIA NoI and hopefully reach a technical consensus around that. Maybe we consider one of these approaches acceptable. Or perhaps one of them is unacceptable. Or somehere in between, who knows? And if it's not possible to get a technical consensus from the WG by the deadline, then I hope we can at least agree on some common statement that can be submitted in time: perhaps something neutral but encouraging like "we welcome the NTIA NoI as a positive step towards getting the root signed". However even that depends on the WG discussing the subject. Or if there's no interest or we feel this topic isn't any business of this WG, we can just give up. Which again needs the members of the list to speak up. So, to back up a bit, let me ask the WG some direct questions: [1] Do we care about the NTIA NoI? [2] Should the WG (try to) formulate a response to that NoI? [3] If the answer to [2] is no, why not? [4] If the answer to [2] is yes, what sort of response should the WG try to send? [5] If that response has a technical component, how do we reach a consensus?
On Wed, Oct 15, 2008 at 11:17:39AM +0200, Florian Weimer wrote:
* Jim Reid:
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list.
I asked them a procedural question about the comment process and haven't received a reply. Maybe non-citizens aren't eligible to comment. 8-/
they are allowed and encouraged.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra_e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Wed, Oct 15, 2008 at 10:12:17AM +0100, Jim Reid wrote:
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Over to you....
rough take: #4 is touted as the offical ICANN postion #5 is touted as the offical Verisign postion both ICANN and Verisign are claiming that placing all the zone creation, change and publication should be with the same organization that creates, hold and uses the digital signatures attesting to the integrity of the zone data. in local parlance, this is the functional equivalence of the fox watching the hen house. options #3 and #6 move the key creation & maintainance along w/ the signing of the zone data to a third party. this type of practice is common, where an auditor or notary validates the presented data. option #6 has the attribute of not having any significant real world deployment - the M of N code and operational practice may not be ready for adoption for such a system. So my general leaning is toward #3 - it provides increased diversity/oversight of the process. --bill
On 15/10/08 8:05 AM, "bmanning@vacation.karoshi.com" <bmanning@vacation.karoshi.com> wrote:
both ICANN and Verisign are claiming that placing all the zone creation, change and publication should be with the same organization that creates, hold and uses the digital signatures attesting to the integrity of the zone data.
in local parlance, this is the functional equivalence of the fox watching the hen house.
Sorry Bill, but I don't see how this analogy works at all. How does an uninvolved third party attest the integrity of the data in the root zone? In a DNSSEC-signed world, the ICANN/VeriSign/NTIA troika would presumably still be responsible for the content of the root zone. If we are talking about analogies, I want the md5sum or PGP signature testifying a software package is not tampered with to be generated as close as possible to when the author created the tar file, not by third parties after it had passed through multiple hands. kim
On Wed, Oct 15, 2008 at 08:36:09AM -0700, Kim Davies wrote:
On 15/10/08 8:05 AM, "bmanning@vacation.karoshi.com" <bmanning@vacation.karoshi.com> wrote:
both ICANN and Verisign are claiming that placing all the zone creation, change and publication should be with the same organization that creates, hold and uses the digital signatures attesting to the integrity of the zone data.
in local parlance, this is the functional equivalence of the fox watching the hen house.
Sorry Bill, but I don't see how this analogy works at all. How does an uninvolved third party attest the integrity of the data in the root zone? In a DNSSEC-signed world, the ICANN/VeriSign/NTIA troika would presumably still be responsible for the content of the root zone.
thats ok, i said it was local. if you are not familiar with the roll of company/security auditors or the use of notory publics, then perhaps knowledge in that area would be helpful in understanding my concerns.
If we are talking about analogies, I want the md5sum or PGP signature testifying a software package is not tampered with to be generated as close as possible to when the author created the tar file, not by third parties after it had passed through multiple hands.
nothing stops VSGN from continuing to provide the MD5sum on the data it ships.
kim
--bill
Bill, On Oct 15, 2008, at 9:09 AM, bmanning@vacation.karoshi.com wrote:
thats ok, i said it was local. if you are not familiar with the roll of company/security auditors or the use of notory publics, then perhaps knowledge in that area would be helpful in understanding my concerns.
If you are not familiar with the way root zone changes are introduced, then perhaps knowledge in that area would be helpful in understanding how your concerns are misplaced. NTIA provides the roll of auditor. That would not be changing, regardless of who signs the root. DNSSEC-signing the root is a purely technical action that allows one to ensure the content of the root zone has not been modified from the point it was signed to the point where it is viewed. It does nothing more. It grants no additional levers of power or control. If you feel otherwise, please provide explicit details. Getting the root signed has been derailed by exactly this sort of baseless, non-technical politicization. It's way past time to move forward. Regards, -drc
On Wed, Oct 15, 2008 at 12:53:39PM -0700, David Conrad wrote:
Bill,
On Oct 15, 2008, at 9:09 AM, bmanning@vacation.karoshi.com wrote:
thats ok, i said it was local. if you are not familiar with the roll of company/security auditors or the use of notory publics, then perhaps knowledge in that area would be helpful in understanding my concerns.
If you are not familiar with the way root zone changes are introduced, then perhaps knowledge in that area would be helpful in understanding how your concerns are misplaced.
thank you for the educational update. based on the published documents from NTIA, it has not changed since I was directly involved.
If you feel otherwise, please provide explicit details.
I will be submitting a response to the NoI that will outline my feelings ... explict detail about my feelings are not likely to be included. my reading of the six proffered models had, for me, a couple of clear winners, with one emerging as the clear favorite for adoption in the near term. others, including yourself, clearly have their own biases. i don't expect to convert you to the one true way and it is unlikely that i will suaded by your persausive enticements.
It's way past time to move forward.
Indeed. Which is why it is important for each person to review the NoI and provide feedback on the relative strengths and weaknesses in each proposal. end of the day, any of the proposals could work to get the root signed - perhaps as early as this calander year. technical merit may not be the only factor.
Regards, -drc
--bill
Bill, On Oct 15, 2008, at 8:05 AM, bmanning@vacation.karoshi.com wrote:
both ICANN and Verisign are claiming that placing all the zone creation, change and publication should be with the same organization that creates, hold and uses the digital signatures attesting to the integrity of the zone data.
in local parlance, this is the functional equivalence of the fox watching the hen house.
This is the kind of FUD that really annoys me. It is attributing some magical quality to zone signing that doesn't actually exist. In the ICANN-signs option, the only real change is that IANA would generate the (signed) zone, with VeriSign publishing the zone after authorization from DoC. In the VeriSign-signs option, the only real change is that VeriSign signs the zone after being authorized to make the zone changes by DoC. In both cases, all zone changes must be: a) vetted by IANA staff b) authorized by DoC c) published by VeriSign prior to getting out to the root servers. How _exactly_ does adding signing make this "the functional equivalen[t] of the fox watching the hen house"? Once more with feeling: the ONLY thing signing the root zone does is to allow for the contents of that zone to be validated. It hides no information. It provides no new mechanisms for subterfuge. Regards, -drc
On Wed, 15 Oct 2008, David Conrad wrote:
Once more with feeling: the ONLY thing signing the root zone does is to allow for the contents of that zone to be validated. It hides no information. It provides no new mechanisms for subterfuge.
And indeed, anyone can still decide to add or remove trust anchors by configuring it in your resolver. So country X can decide to use a signed root, while stll removing country Y effectively from their signed root. Paul
Jim Reid wrote: Jim, for me it seems - that it will raise governance issues and it is not technical problem - but more political and legal issue. I really worry about potential consequences of all these intentions to deploy on the net some digital signatures based techniques (aka DNSSEC, sidr) It is very risky and can provocate Internet fragmentation. We can try to improve security and stability - but in result we can get totally different Internet - it is like as some kind of Pandora box. Dmitry
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
This is an argument that has repeated itself for some time now, with few arguments to back it. Perhaps those with doubts about how a signed zone might be wielded as a weapon against some party, would be interested in performing an analysis of what the possible reactions are to such an attempt and compare both the actions and their result to today's situation with an unsigned zone. Then for the extra bonus, analyse the benefits of having a signed zone when it is not being wielded as a weapon (assuming the previous analysis actually finds that possibility to be real) Joao Damas On 15/10/2008, at 18:41, Dmitry Burkov wrote:
Jim Reid wrote:
Jim, for me it seems - that it will raise governance issues and it is not technical problem - but more political and legal issue. I really worry about potential consequences of all these intentions to deploy on the net some digital signatures based techniques (aka DNSSEC, sidr) It is very risky and can provocate Internet fragmentation. We can try to improve security and stability - but in result we can get totally different Internet - it is like as some kind of Pandora box.
Dmitry
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
Joao, to be realistic - the most probable reaction will be refuse to sign with all following consequences. SIDR deployment (as it propsed today) it will be a real problem. DNSSEC deployment will be less problematic but still a problem as it will be used in software more and more. It also raises an old question about Internet governance and role of USG in this process as will enforce DoC position. Some people for years tried to explain root servers stability and practical independence from any one government now their arguments will fall down. In any of NTIA's proposed scheme it will be under one country regulation and if previously you can imagine partly functional ccTLDs even if zone was changed - now if signature will be invalid/recalled (don't know term in english) it will be more problematic. When we begin to use digital signatures for infrastructure - may be, we miss the point that this tool is just a reflection of some real world relations and obligations and based on national laws and other lawyer stuff. Putting it on this part of the net we risk to involve all issues from real world. And all benefits which you mentioned and which I understand and recognize from technical point of view will be non significant. regards, Dmitry Joao Damas ?????:
This is an argument that has repeated itself for some time now, with few arguments to back it.
Perhaps those with doubts about how a signed zone might be wielded as a weapon against some party, would be interested in performing an analysis of what the possible reactions are to such an attempt and compare both the actions and their result to today's situation with an unsigned zone. Then for the extra bonus, analyse the benefits of having a signed zone when it is not being wielded as a weapon (assuming the previous analysis actually finds that possibility to be real)
Joao Damas
On 15/10/2008, at 18:41, Dmitry Burkov wrote:
Jim Reid wrote:
Jim, for me it seems - that it will raise governance issues and it is not technical problem - but more political and legal issue. I really worry about potential consequences of all these intentions to deploy on the net some digital signatures based techniques (aka DNSSEC, sidr) It is very risky and can provocate Internet fragmentation. We can try to improve security and stability - but in result we can get totally different Internet - it is like as some kind of Pandora box.
Dmitry
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
Dmitry, my mail was not technical at all. How does the state of affairs change from today? what are your reaction possibilities and their impact and how do they differ from today's scenario? Does the signing of the root zone actually impede or make harder any of the reactions you would exercise today against, for example, the deletion of a ccTLD from the root zone? is there an analysis of how zone signing changes any of this? Joao On 20/10/2008, at 16:42, Dmitry Burkov wrote:
Joao, to be realistic - the most probable reaction will be refuse to sign with all following consequences. SIDR deployment (as it propsed today) it will be a real problem. DNSSEC deployment will be less problematic but still a problem as it will be used in software more and more.
It also raises an old question about Internet governance and role of USG in this process as will enforce DoC position. Some people for years tried to explain root servers stability and practical independence from any one government now their arguments will fall down. In any of NTIA's proposed scheme it will be under one country regulation and if previously you can imagine partly functional ccTLDs even if zone was changed - now if signature will be invalid/recalled (don't know term in english) it will be more problematic.
When we begin to use digital signatures for infrastructure - may be, we miss the point that this tool is just a reflection of some real world relations and obligations and based on national laws and other lawyer stuff. Putting it on this part of the net we risk to involve all issues from real world.
And all benefits which you mentioned and which I understand and recognize from technical point of view will be non significant.
regards, Dmitry
Joao Damas ?????:
This is an argument that has repeated itself for some time now, with few arguments to back it.
Perhaps those with doubts about how a signed zone might be wielded as a weapon against some party, would be interested in performing an analysis of what the possible reactions are to such an attempt and compare both the actions and their result to today's situation with an unsigned zone. Then for the extra bonus, analyse the benefits of having a signed zone when it is not being wielded as a weapon (assuming the previous analysis actually finds that possibility to be real)
Joao Damas
On 15/10/2008, at 18:41, Dmitry Burkov wrote:
Jim Reid wrote:
Jim, for me it seems - that it will raise governance issues and it is not technical problem - but more political and legal issue. I really worry about potential consequences of all these intentions to deploy on the net some digital signatures based techniques (aka DNSSEC, sidr) It is very risky and can provocate Internet fragmentation. We can try to improve security and stability - but in result we can get totally different Internet - it is like as some kind of Pandora box.
Dmitry
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
Joao, not exactly and immediately today. The problem is that new tool will be used in software and especially end-user soft. As it will happen the situation will be changed radically. Or I am madness or something miss. Dmitry Joao Damas ?????:
Dmitry, my mail was not technical at all. How does the state of affairs change from today? what are your reaction possibilities and their impact and how do they differ from today's scenario? Does the signing of the root zone actually impede or make harder any of the reactions you would exercise today against, for example, the deletion of a ccTLD from the root zone? is there an analysis of how zone signing changes any of this?
Joao
On 20/10/2008, at 16:42, Dmitry Burkov wrote:
Joao, to be realistic - the most probable reaction will be refuse to sign with all following consequences. SIDR deployment (as it propsed today) it will be a real problem. DNSSEC deployment will be less problematic but still a problem as it will be used in software more and more.
It also raises an old question about Internet governance and role of USG in this process as will enforce DoC position. Some people for years tried to explain root servers stability and practical independence from any one government now their arguments will fall down. In any of NTIA's proposed scheme it will be under one country regulation and if previously you can imagine partly functional ccTLDs even if zone was changed - now if signature will be invalid/recalled (don't know term in english) it will be more problematic.
When we begin to use digital signatures for infrastructure - may be, we miss the point that this tool is just a reflection of some real world relations and obligations and based on national laws and other lawyer stuff. Putting it on this part of the net we risk to involve all issues from real world.
And all benefits which you mentioned and which I understand and recognize from technical point of view will be non significant.
regards, Dmitry
Joao Damas ?????:
This is an argument that has repeated itself for some time now, with few arguments to back it.
Perhaps those with doubts about how a signed zone might be wielded as a weapon against some party, would be interested in performing an analysis of what the possible reactions are to such an attempt and compare both the actions and their result to today's situation with an unsigned zone. Then for the extra bonus, analyse the benefits of having a signed zone when it is not being wielded as a weapon (assuming the previous analysis actually finds that possibility to be real)
Joao Damas
On 15/10/2008, at 18:41, Dmitry Burkov wrote:
Jim Reid wrote:
Jim, for me it seems - that it will raise governance issues and it is not technical problem - but more political and legal issue. I really worry about potential consequences of all these intentions to deploy on the net some digital signatures based techniques (aka DNSSEC, sidr) It is very risky and can provocate Internet fragmentation. We can try to improve security and stability - but in result we can get totally different Internet - it is like as some kind of Pandora box.
Dmitry
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
On Oct 20, 2008, at 15:42, Dmitry Burkov wrote:
It also raises an old question about Internet governance and role of USG in this process as will enforce DoC position. Some people for years tried to explain root servers stability and practical independence from any one government now their arguments will fall down. In any of NTIA's proposed scheme it will be under one country regulation and if previously you can imagine partly functional ccTLDs even if zone was changed - now if signature will be invalid/recalled (don't know term in english) it will be more problematic.
Dima, these questions will always be raised. Even if nothing is ever done to the root. The point Joao made earlier still goes unanswered. With an unsigned root, all changes to add, remove or update data in the zone involve co-ordination with the DoC/NTIA. If/when the root is signed, all changes to the root zone will still involve co-ordination with the DoC/NTIA. So what's different?
When we begin to use digital signatures for infrastructure - may be, we miss the point that this tool is just a reflection of some real world relations and obligations and based on national laws and other lawyer stuff. Putting it on this part of the net we risk to involve all issues from real world.
I appreciate that some people will feel that legal agreements are an unavoidable consequence of signing. However that's a matter between the each TLD (and its government?) and those co-ordinating the root. There are no technical grounds for parent and child zones to have a legal agreement underpinning their use of DNSSEC. So if a TLD wants to have a signed delegation, they can do that with or without an agreement or anything that could be viewed as an acceptance of the way the root is managed today. If a TLD doesn't want to have a signed delegation, then they don't have to. Nobody's being compelled to do anything they don't want. And as far as I can tell, nothing's being proposed that will compromise security or stability. Though there are obvious technical and operational concerns about where the key(s) get stored, how their managed and who's involved in that. IMO, there's no "lawyer stuff" here. At least as far as signing the root is concerned. All that's happening is some TLD presents its KSK, IANA verifies that key and then causes a signature over that key to be generated. Which pretty much means that IANA is saying "we assert that this was the TLD KSK that we checked": nothing more. Now there may well be lawyer stuff further down the tree. For instance suppose .ru is signed. I would expect that the .ru registry would have to consult the Russian government and Russian law about what that means nationally. But that is what's known in international law as a National Matter and isn't anyone else's business. Likewise, they may well need to consult widely inside Russia before submitting a KSK for .ru to the signed root, if that was in place.
Jim Reid wrote: Jim, for me the issue - as I wrote in previous email to Joao - it is how it can be used in software in future. Depending on this - it can be critical. Second point - how it will be used for .arpa Third point (not related to DNS - sorry - but simular problem) - sidr and it's deployment. After that I want to remind that the political world is not hierarchical - and when we put something with legal background to technical implementation it will immediately raise political issues as it does not reflect reality. It seems me a problem even all of us have the best intentions. regards, Dima
On Oct 20, 2008, at 15:42, Dmitry Burkov wrote:
It also raises an old question about Internet governance and role of USG in this process as will enforce DoC position. Some people for years tried to explain root servers stability and practical independence from any one government now their arguments will fall down. In any of NTIA's proposed scheme it will be under one country regulation and if previously you can imagine partly functional ccTLDs even if zone was changed - now if signature will be invalid/recalled (don't know term in english) it will be more problematic.
Dima, these questions will always be raised. Even if nothing is ever done to the root. The point Joao made earlier still goes unanswered. With an unsigned root, all changes to add, remove or update data in the zone involve co-ordination with the DoC/NTIA. If/when the root is signed, all changes to the root zone will still involve co-ordination with the DoC/NTIA. So what's different?
When we begin to use digital signatures for infrastructure - may be, we miss the point that this tool is just a reflection of some real world relations and obligations and based on national laws and other lawyer stuff. Putting it on this part of the net we risk to involve all issues from real world.
I appreciate that some people will feel that legal agreements are an unavoidable consequence of signing. However that's a matter between the each TLD (and its government?) and those co-ordinating the root. There are no technical grounds for parent and child zones to have a legal agreement underpinning their use of DNSSEC. So if a TLD wants to have a signed delegation, they can do that with or without an agreement or anything that could be viewed as an acceptance of the way the root is managed today. If a TLD doesn't want to have a signed delegation, then they don't have to. Nobody's being compelled to do anything they don't want.
And as far as I can tell, nothing's being proposed that will compromise security or stability. Though there are obvious technical and operational concerns about where the key(s) get stored, how their managed and who's involved in that.
IMO, there's no "lawyer stuff" here. At least as far as signing the root is concerned. All that's happening is some TLD presents its KSK, IANA verifies that key and then causes a signature over that key to be generated. Which pretty much means that IANA is saying "we assert that this was the TLD KSK that we checked": nothing more.
Now there may well be lawyer stuff further down the tree. For instance suppose .ru is signed. I would expect that the .ru registry would have to consult the Russian government and Russian law about what that means nationally. But that is what's known in international law as a National Matter and isn't anyone else's business. Likewise, they may well need to consult widely inside Russia before submitting a KSK for .ru to the signed root, if that was in place.
On Oct 20, 2008, at 17:55, Dmitry Burkov wrote:
for me the issue - as I wrote in previous email to Joao - it is how it can be used in software in future.
I'm not sure I understand the question Dima. DNSSEC is an enabling technology because it gives new opportunities (and challenges) to developers. If data from the DNS can be verified, that opens up all sorts of possibilities. One technical question that could be asked here is "what happens when idiot developers embed the root key in an embedded system (say) and then the root key changes?". Is that what you're asking about?
Depending on this - it can be critical.
Second point - how it will be used for .arpa
See above. We already have some (limited) experience here with the NCC's efforts to sign parts of the reverse tree.
Third point (not related to DNS - sorry - but simular problem) - sidr and it's deployment.
I think it's unwise to link these. Though I suppose a signed part of the DNS name space would make it a whole lot easier to lookup and verify (secure) routing announcements.
Jim Reid wrote:
On Oct 20, 2008, at 17:55, Dmitry Burkov wrote:
for me the issue - as I wrote in previous email to Joao - it is how it can be used in software in future.
I'm not sure I understand the question Dima. DNSSEC is an enabling technology because it gives new opportunities (and challenges) to developers. If data from the DNS can be verified, that opens up all sorts of possibilities.
One technical question that could be asked here is "what happens when idiot developers embed the root key in an embedded system (say) and then the root key changes?". Is that what you're asking about?
Jim, I hope that you remember laws of Murphy and Peter... or if it can happen it will happen and so on...
Depending on this - it can be critical.
Second point - how it will be used for .arpa
See above. We already have some (limited) experience here with the NCC's efforts to sign parts of the reverse tree.
the same problem will increase
Third point (not related to DNS - sorry - but simular problem) - sidr and it's deployment.
I think it's unwise to link these. Though I suppose a signed part of the DNS name space would make it a whole lot easier to lookup and verify (secure) routing announcements.
But sidr deployed will raise more issue as potential "red button". I want to return to your previous example with .ru. I don't think that it could really happen with .ru - but I can easily can imagine this situation with some other country. But when some probability exists I personally worry - as we can create potentially dangerous tool with the best intentions. When in our world services for citizens more and more depends on Internet - I really worry about principal changes in Internet architecture. If before we defacto have a system which was depended on more techies - person and professional-based responsibility - in future we can get more automated system which will lose this previous basement and can become a weapon in hands of politicals. Dima
On Oct 20, 2008, at 18:25, Dmitry Burkov wrote:
I hope that you remember laws of Murphy and Peter... or if it can happen it will happen and so on...
Indeed. But I worry about how those laws could be applied to the current insecure DNS. This is a much, much bigger danger than getting the root signed. What we've seen so far with cache poisoning attacks has been bad. And it will get worse. Meanwhile, we have a technology that works that can pretty much eliminate that problem. But it's blocked by layer-9 problems. So far. The NTIA NoI is at least a step forward to removing those obstacles.
When in our world services for citizens more and more depends on Internet - I really worry about principal changes in Internet architecture.
I agree. But I don't see signing the root like that. It will allow those TLDs who want to deploy DNSSEC to proceed without ugly hacks that probably won't help in the long run. But signing the root won't have any impact on the TLDs who don't want to sign their zone. Similarly, those who *use* DNSSEC will know what they're getting in to and take the appropriate decisions to mitigate those risks. Those who won't use DNSSEC will just carry on as if the root was never signed: they'll see no difference. Well, except from an increased exposure to security attacks predicated on DNS spoofing.
If before we defacto have a system which was depended on more techies - person and professional-based responsibility - in future we can get more automated system which will lose this previous basement and can become a weapon in hands of politicals.
Politicians and governments win out in the end. They always do. One of the questions for this WG (and others) to consider is how well the NTIA proposals accommodate the various conflicting demands from engineers, lawyers and politicians.
At 19:09 +0100 10/20/08, Jim Reid wrote:
Politicians and governments win out in the end. They always do. One of the questions for this WG (and others) to consider is how well the NTIA proposals accommodate the various conflicting demands from engineers, lawyers and politicians.
Don't make this more political than it is. The proposals are in a section called "Six Possible Process Flow Models." The NTIA is not saying, here are 6, vote. It's saying "tell us, and here's kinda what we are thinking." Be technical. Be what you do best. Don't try to beat politicians at their game. Bad strategy, I've found. One reason I am not offering my opinion here is that I'd rather 100 people write against what I'd say from their own minds and not to pick a fight. A hundred genuine opinions is better than a thousand "me too's" or "not me too's." Besides, my idea involves a team of trained monkeys, explosive bolts, three clowns, an asteroid and a capsized oil rig. If nothing else, it'd be real cool. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Jim Reid wrote:
On Oct 20, 2008, at 18:25, Dmitry Burkov wrote:
I hope that you remember laws of Murphy and Peter... or if it can happen it will happen and so on...
Indeed. But I worry about how those laws could be applied to the current insecure DNS. This is a much, much bigger danger than getting the root signed. What we've seen so far with cache poisoning attacks has been bad. And it will get worse. Meanwhile, we have a technology that works that can pretty much eliminate that problem. But it's blocked by layer-9 problems. So far. The NTIA NoI is at least a step forward to removing those obstacles.
Jim, imagine different appoach/view - that signed root can be more dangerous (potentially) for some countries then unsigned. Do you really believe in best intentions of some governements as they expressed their itentions during last few months. I can only repeat that as engineer I understood you and - to be honest will try to do the same in idealistic world. But as I live here - on the earth - I will try escape potential problems before it create a real problems. For me - it seems - we should openly discuss potential consequences for countries as we will introduce this tools. I heard a lot of opinions that it is just a technical issue - and that it is wrong to discuss it in political context. I hope that it is just an misunderstanding - and guys can understand that this small and long expected change can have different meaning then they expect before.
When in our world services for citizens more and more depends on Internet - I really worry about principal changes in Internet architecture.
I agree. But I don't see signing the root like that. It will allow those TLDs who want to deploy DNSSEC to proceed without ugly hacks that probably won't help in the long run. But signing the root won't have any impact on the TLDs who don't want to sign their zone. Similarly, those who *use* DNSSEC will know what they're getting in to and take the appropriate decisions to mitigate those risks. Those who won't use DNSSEC will just carry on as if the root was never signed: they'll see no difference. Well, except from an increased exposure to security attacks predicated on DNS spoofing.
The problem will be in future software development from one side - the second - and may be more important that we will enforce word to split on a camps. I am really don't want it - and it is a key point for me.
If before we defacto have a system which was depended on more techies - person and professional-based responsibility - in future we can get more automated system which will lose this previous basement and can become a weapon in hands of politicals.
Politicians and governments win out in the end. They always do. One of the questions for this WG (and others) to consider is how well the NTIA proposals accommodate the various conflicting demands from engineers, lawyers and politicians.
for me - it is a way to hell. thanks, Dima
Dima, On Oct 20, 2008, at 9:55 AM, Dmitry Burkov wrote:
for me the issue - as I wrote in previous email to Joao - it is how it can be used in software in future.
As I'm sure you're aware, the only thing DNSSEC-signing the root does is allow for validating resolvers to verify the data from the root zone hasn't been modified from the point at which it was signed to the point at which it is used by the validating resolver. If {IANA,VeriSign,NTIA} were to do something "bad", the contents of the root zone would be altered, regardless of whether the root zone were signed. In order to avoid this badness, operators of caching servers would need to modify their root hints to point to root servers serving non-bad data or take other steps that mucked with the caching server's configuration. If the root were DNSSEC-signed, the configuration mucking would need to include changing the root trust anchor. I don't see the significantly increased risk here by adding DNSSEC.
After that I want to remind that the political world is not hierarchical - and when we put something with legal background to technical implementation it will immediately raise political issues as it does not reflect reality.
Sorry? What legal background are you talking about? As for reflecting reality, I'm gathering what you're referencing is the fact that the US government has an authorization role in root management. First: none of the scenarios for DNSSEC-signing the root changes this, so we'd be no better or worse off than we are now. Second: lots of governments, many of which are in Europe, support the US government having the role it does in root zone management. Given this, I suspect it is unlikely there will be a change in roles for the foreseeable future. It would be unfortunate if DNSSEC-signing the root were held back because of this. Regards, -drc
David Conrad wrote:
Dima,
On Oct 20, 2008, at 9:55 AM, Dmitry Burkov wrote:
for me the issue - as I wrote in previous email to Joao - it is how it can be used in software in future.
As I'm sure you're aware, the only thing DNSSEC-signing the root does is allow for validating resolvers to verify the data from the root zone hasn't been modified from the point at which it was signed to the point at which it is used by the validating resolver. If {IANA,VeriSign,NTIA} were to do something "bad", the contents of the root zone would be altered, regardless of whether the root zone were signed. In order to avoid this badness, operators of caching servers would need to modify their root hints to point to root servers serving non-bad data or take other steps that mucked with the caching server's configuration. If the root were DNSSEC-signed, the configuration mucking would need to include changing the root trust anchor
David, technically you are right - but you missed the point that with introducing one repository in one jurisdiction we will get a problem especially when software vendors will deploy new features.
I don't see the significantly increased risk here by adding DNSSEC.
David, you missed one point - lost of trust - it was one of the items that were practically unchanged for years and became defacto. During all last dicussions on internet governance it was one argues pro stability and practical independance - what we can say today?
After that I want to remind that the political world is not hierarchical - and when we put something with legal background to technical implementation it will immediately raise political issues as it does not reflect reality.
Sorry? What legal background are you talking about?
It is enough easy - digital signatures based on concrete laws in different countries which are incompatible - please, check.
As for reflecting reality, I'm gathering what you're referencing is the fact that the US government has an authorization role in root management. First: none of the scenarios for DNSSEC-signing the root changes this, so we'd be no better or worse off than we are now. Second: lots of governments, many of which are in Europe, support the US government having the role it does in root zone management. Given this, I suspect it is unlikely there will be a change in roles for the foreseeable future. It would be unfortunate if DNSSEC-signing the root were held back because of this.
For me the situation seems worse - it is just personal opinion - but I tried to express it - no more. It is not an argument that some countries support one country or even a lot of them - discussing this issue we are in different dimension when no one can dictate others. Hope you can understand me - that we should recognize national independance (sorry guys for this words - but I can't miss it). Sometimes, majority can mistaken. Unfortunately, we can't put this world in just our technocracy models... Dima
Regards, -drc
Dima, On Oct 20, 2008, at 1:54 PM, Dmitry Burkov wrote:
technically you are right - but you missed the point that with introducing one repository in one jurisdiction we will get a problem especially when software vendors will deploy new features.
So, you're arguing against DNSSEC as defined, not just signing the root. Apologies if I misunderstood.
you missed one point - lost of trust - it was one of the items that were practically unchanged for years and became defacto.
You appear to be asserting that {IANA,VeriSign,NTIA} doing something "bad" is somehow worse if it gets DNSSEC-signed. I don't get it. If {IANA,VeriSign,NTIA} does something that causes loss of trust, then trust is lost. The fact that the bad change can be verified by caching servers as accurate in such a case seems irrelevant to me.
During all last dicussions on internet governance it was one argues pro stability and practical independance - what we can say today?
That DNSSEC doesn't significantly change the trustworthy-ness of the data prior to it getting signed, but does ensure that that data, once signed, can be validated. No more and no less.
Sorry? What legal background are you talking about? It is enough easy - digital signatures based on concrete laws in different countries which are incompatible - please, check.
Sorry, still don't get it. All we're talking about here is providing an ability to detect data has been modified from the point where somebody (IANA, VeriSign, a third party) signs it to the validating resolver. No one to my knowledge is proposing there be a legally binding attestation that said data is accurate. I'm not even sure such an attestation would make sense even if somebody was trying to make it.
Hope you can understand me - that we should recognize national independance (sorry guys for this words - but I can't miss it).
Are you familiar with the colloquialism "trying to close the barn door after the horses have bolted"? In 1996, the US government unilaterally asserted it had the right/ responsibility to make these sorts of decisions. No (zero, none, nada) government complained at the time (much to my personal annoyance). Since then, processes have been worked out that allow for changes to be made with the US government acting only in an authorization role, presumably in order to prevent ICANN or VeriSign from running amok and destroying the Internet. Now, a dozen years later, the US Dept. of Commerce is asking for input on a set of scenarios that will allow for a sucking chest wound that has existed in the DNS since its creation to (eventually) be fixed. If you think DNSSEC is a bad idea, that's fine input to provide. If you think one scenario is better than another, saying so (and giving reasons) would be ideal. But saying DNSSEC-signing threatens national independence isn't likely going to help anything unless you can give concrete justification why you believe DNSSEC-signing has an impact one way or another. Regards, -drc
On Mon, Oct 20, 2008 at 10:58:07AM -0700, David Conrad <drc@virtualized.org> wrote a message of 39 lines which said:
Second: lots of governments, many of which are in Europe, support the US government having the role it does in root zone management.
Indeed, many NATO countries support their ally, the USA. But this is not the sort of reasoning that will convince people in Brazil, Russia or India...
On Mon, Oct 20, 2008 at 05:26:12PM +0100, Jim Reid wrote:
I appreciate that some people will feel that legal agreements are an unavoidable consequence of signing. However that's a matter between the each TLD (and its government?) and those co-ordinating the root. There are no technical grounds for parent and child zones to have a legal agreement underpinning their use of DNSSEC. So if a TLD wants to have a signed delegation, they can do that with or without an agreement or anything that could be viewed as an acceptance of the way the root is managed today. If a TLD doesn't want to have a signed delegation, then they don't have to. Nobody's being compelled to do anything they don't want.
well... as Lutz has demostrated, its often difficult to have a signed delegation and also be able to restrict whom picks up your DNSKEY and plops it into their version of the parent delegation.
All that's happening is some TLD presents its KSK, IANA verifies that key and then causes a signature over that key to be generated. Which pretty much means that IANA is saying "we assert that this was the TLD KSK that we checked": nothing more.
perhaps, if one buys into the argument that there is only a single parent. the .RU folks may want their signed data to only follow the JIMREID-root-o-ultimate-correctness and not appear at all in those fly-by-night outfits (PACROOT, ORSN, ICANN & RS.NET) ... harvesting DNSKEYS seems to be a very lightweight means of "asserting that this was the TLD-KSK that we checked".
Likewise, they may well need to consult widely inside Russia before submitting a KSK for .ru to the signed root, if that was in place.
DNSKEY harvesting is a means to avoid having a formal means to submit your data to your parent ... any/everyone can pick it up and claim your ancestry. --bill
bmanning@vacation.karoshi.com wrote:
On Mon, Oct 20, 2008 at 05:26:12PM +0100, Jim Reid wrote:
I appreciate that some people will feel that legal agreements are an unavoidable consequence of signing. However that's a matter between the each TLD (and its government?) and those co-ordinating the root. There are no technical grounds for parent and child zones to have a legal agreement underpinning their use of DNSSEC. So if a TLD wants to have a signed delegation, they can do that with or without an agreement or anything that could be viewed as an acceptance of the way the root is managed today. If a TLD doesn't want to have a signed delegation, then they don't have to. Nobody's being compelled to do anything they don't want.
well... as Lutz has demostrated, its often difficult to have a signed delegation and also be able to restrict whom picks up your DNSKEY and plops it into their version of the parent delegation.
DNSKEY is just a Resource Record, just like NS. The same arguments apply to both, with equal meaning technically. People are applying meaning to DNSSEC-related stuff that it does not actually have. For some reason you are adding fuel to that fire. Doug
Doug Barton wrote:
bmanning@vacation.karoshi.com wrote:
On Mon, Oct 20, 2008 at 05:26:12PM +0100, Jim Reid wrote:
I appreciate that some people will feel that legal agreements are an unavoidable consequence of signing. However that's a matter between the each TLD (and its government?) and those co-ordinating the root. There are no technical grounds for parent and child zones to have a legal agreement underpinning their use of DNSSEC. So if a TLD wants to have a signed delegation, they can do that with or without an agreement or anything that could be viewed as an acceptance of the way the root is managed today. If a TLD doesn't want to have a signed delegation, then they don't have to. Nobody's being compelled to do anything they don't want.
well... as Lutz has demostrated, its often difficult to have a signed delegation and also be able to restrict whom picks up your DNSKEY and plops it into their version of the parent delegation.
DNSKEY is just a Resource Record, just like NS. The same arguments apply to both, with equal meaning technically. People are applying meaning to DNSSEC-related stuff that it does not actully have. For some reason you are adding fuel to that fire.
Doug, please, change you mind - it is not just a Record. You will begin to use all the stuff that have different background in real - non network life with all problems that it will arise. Dima
Doug
Bill, On Oct 20, 2008, at 11:34 AM, bmanning@vacation.karoshi.com wrote:
perhaps, if one buys into the argument that there is only a single parent.
So, just to be clear, you're arguing the root shouldn't be signed and instead each validating resolver operator should harvest DNSKEYs of all zones that are signed? Couldn't you harvest DNSKEYs regardless of whether the root is signed or not? Thanks, -drc
On Mon, Oct 20, 2008 at 03:50:46PM -0700, David Conrad wrote:
Bill,
On Oct 20, 2008, at 11:34 AM, bmanning@vacation.karoshi.com wrote:
perhaps, if one buys into the argument that there is only a single parent.
So, just to be clear, you're arguing the root shouldn't be signed and instead each validating resolver operator should harvest DNSKEYs of all zones that are signed?
no i am not. i report that the action of harvesting DNSKEYs and installing them into a zone purporting to be a parent is currently common practice. i have said nothing in this thread about the desirability or not of having signed zones. what can be infered is that there are and will be many parties claiming to be "the root" and there is currently little to distinguish one from the other. even if one signs ones TLD, there is zero assurance that only a single root will harvest the DNSKEY and install it in their version of "the root".
Couldn't you harvest DNSKEYs regardless of whether the root is signed or not?
I could (but will not). Lutz can and does harvest DNSKEYs and installs them in the root. Its just not your version of "the root". It's not mine either. But then, mine is not shared by too many.
Thanks, -drc
Your Welcome, --bill
On Mon, Oct 20, 2008 at 05:26:12PM +0100, Jim Reid wrote:
IMO, there's no "lawyer stuff" here. At least as far as signing the root is concerned. All that's happening is some TLD presents its KSK, IANA verifies that key and then causes a signature over that key to be generated. Which pretty much means that IANA is saying "we assert that this was the TLD KSK that we checked": nothing more.
IMHO it is important to emphasize that the semantics are in the DS RR, not in the RRSIG(DS). The latter only authenticates the (technically authoritative) DS RR in the parent zone. At least in theory, one could start to publish DS RRs without signing them. -Peter
On Wed, Oct 15, 2008 at 10:12:17AM +0100, Jim Reid <jim@rfc1035.com> wrote a message of 20 lines which said:
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
One may think that replying to a US government consultation (whatever the content of the reply) means an approval of its unilateral decision to manage the root... After all, why such a consultation for an international resource is managed by one governement?
On Oct 21, 2008, at 10:20, Stephane Bortzmeyer wrote:
One may think that replying to a US government consultation (whatever the content of the reply) means an approval of its unilateral decision to manage the root...
People can think all sorts of things. Whether they're true or not is another matter. The facts here are the NTIA consultation is the only game in town. As you no doubt know Stephane ICANN/IANA was slapped down when it tried to do its own consultation on signing the root earlier this year. Any other forum that tried to run a consulation on this subject would either be ignored or also get put in its place by NTIA/DoC. So the choice here is stark: contribute to the NTIA exercise or shun it.
After all, why such a consultation for an international resource is managed by one governement?
Please take a discussion about the international aspects of root zone politics elsewhere. It doesn't belong in this WG. If you feel that this WG should not respond to the NTIA NoI because it "recognises" USG oversight of the root zone, that is in scope for the WG. In other words the WG can discuss whether we should respond to the NTIA consultation or not. But we shouldn't get into a discussion about the hows and whys of USG oversight of the root zone. At least, we won't have that discussion here.
At 11:20 +0200 10/21/08, Stephane Bortzmeyer wrote:
One may think that replying to a US government consultation (whatever the content of the reply) means an approval of its unilateral decision to manage the root...
Then submit that comment to them. Here it counts for nothing.
After all, why such a consultation for an international resource is managed by one governement?
Because they started it, have been doing it, and are paying for the current operations. If you want them to save their money and not do this, express the opinion. When given the change to express an opinion, why not take it? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
On Oct 21, 2008, at 3:16 AM, Edward Lewis wrote:
At 11:20 +0200 10/21/08, Stephane Bortzmeyer wrote:
One may think that replying to a US government consultation (whatever the content of the reply) means an approval of its unilateral decision to manage the root... Then submit that comment to them. Here it counts for nothing.
Yep. However, as long as other governments support the US governmental role, I suspect comments along these lines will not carry much weight. Not to stray too far into international geo-politics, but getting governments to stop telling the US Government in private that they want the US government to continue the role they currently hold would probably be more beneficial in reaching the goal I assume you desire.
After all, why such a consultation for an international resource is managed by one governement? Because they started it, have been doing it, and are paying for the current operations.
Yes, the US government started it and have been doing it (and other governments keep telling them to continue doing it), but they are NOT paying for the current operations, at least IANA operations. And to be clear, pragmatically speaking, the international resource in question (the root zone) is _not_ managed by one government. The US government role has, to date, been limited to authorizing changes proposed by IANA. They do not propose changes nor have they ever altered a change request. Actual management of the root zone is done pretty much as it has always been done since RFC 1591 was published, by folks within IANA, VeriSign, and the root operators. Regards, -drc
On Wed, Oct 15, 2008 at 10:12 AM, Jim Reid <jim@rfc1035.com> wrote:
So far there has been no discussion on the list about the NTIA proposals about getting the root signed. I would have hoped someone would have said something by now. Sigh.
Please try to find some time to look at the NTIA's suggestions and if possible send your comments to the list. I think this WG has an obligation to make some sort of "official" response to the NTIA's consultation. After all, we played our part to get the ball rolling by producing the "sign the root" letter to ICANN at the Tallinn meeting. So now that there are some concrete proposals for consideration, I feel the WG should look at them and respond.
I would also welcome suggestions from WG members about how to stimulate a discussion here about the NTIA proposals. Although time has been set aside in the RIPE57 agenda, that won't be enough. The majority of people on this list won't be in Dubai. And besides, it's really the list that should decide the WG's opinion and what action it should take.
Over to you....
Jim, I agree we need to discuss this as a group and am very interested in hearing people's opinions, I feel that the people from this wg should give their opinions both directly to the NTIA but also the dns-wg forming a collective opinion and sending it to the NTIA can only be a good thing. My comments on the proposal(s) are below. Note these are my comments and opinions and not neccesarilly those of my current employer. Brett. I have read the proposals from both ICANN and Verisign and feel there are positive points to be taken from both proposals. I feel that the function of compiling and signing the root zone should be under the stewardship of a non commercial, non profit driven entity who has internet stability and security as their primary concern, therefore I would support moving this function to ICANN . However one point that I would strongly support from the Verisign proposal is the multi user stewardship of the KSK (the M of N principle) I believe ICANN should incorporate something similar to this in their process, however the organizations chosen to be part of this group need to be very carefully chosen, I would suggest that again they should all be non commercial organizations and represent Internet users from all parts of the globe, for this reason I would suggest that maybe the current RIR's (ARIN, AFRINIC, RIPE, LACNIC and APNIC) would be ideal groups to perform this function. As a non US Citizen I do have some concerns as to why this process is being undertaken by a department of the US Government and not an international multi stakeholder based group. I do not have a strong opinion as to what that group should be but it does seem to obvious to me that it should not be tied to one country whoever that country is. Regards
At 12:43 +0100 10/21/08, B C wrote:
I would suggest that again they should all be non commercial organizations and represent Internet users from all parts of the globe, for this reason I would suggest that maybe the current RIR's (ARIN, AFRINIC, RIPE, LACNIC and APNIC) would be ideal groups to perform this function.
Like this? http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-techsec-ksk-m... http://www.arin.net/meetings/minutes/ARIN_XI/PDF/Tuesday/11_keys_Ihren.pdf Don't know if there was one at APNIC. (LACNIC and AFRINIC weren't in place then.) Five and a half years ago. There were a series of pitches to the RIRs to take the role of KSK monitors. They said "no thanks, we are IP numbers, not Domain Names." Something about separation of duties, not wanting to be tied to the ICANN role, etc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Five and a half years ago. There were a series of pitches to the RIRs to take the role of KSK monitors. They said "no thanks, we are IP numbers, not Domain Names." Something about separation of duties, not wanting to be tied to the ICANN role, etc.
occasionally, the community has a burst of wisdom. fix the iana, don't rebuild the same problem(s) in another place. and the iana has been functionally fixed, thanks drc, br, ... now get it the <bleep> out from under the usg. randy
Hi, On Oct 21, 2008, at 4:43 AM, B C wrote:
However one point that I would strongly support from the Verisign proposal is the multi user stewardship of the KSK (the M of N principle)
Just to be clear, the KSK signing ceremony is something that happens rarely, e.g. O(years). Given the importance of the event, it would seem to me that it would be appropriate for attendance of all observers/participants to be mandatory (if someone isn't able to come for whatever reason, e.g., they've disappeared, that person/entity's role should be reassigned prior to the ceremony). As such, M of N would imply that you could have non-unanimity in the creation of the KSK. This strikes me as a really questionable situation to get into. Given the relative rarity of the KSK generation event, I am unclear as to why the added complexity of M of N is beneficial. Could someone explain? Thanks, -drc
On Tue, 21 Oct 2008, David Conrad wrote:
to get into. Given the relative rarity of the KSK generation event, I am unclear as to why the added complexity of M of N is beneficial. Could someone explain?
So we can filibuster the key rollover? :) Paul
On Tue, 21 Oct 2008, David Conrad wrote:
On Oct 21, 2008, at 4:43 AM, B C wrote:
However one point that I would strongly support from the Verisign proposal is the multi user stewardship of the KSK (the M of N principle)
Just to be clear, the KSK signing ceremony is something that happens rarely, e.g. O(years). Given the importance of the event, it would seem to me that it would be appropriate for attendance of all observers/participants to be mandatory (if someone isn't able to come for whatever reason, e.g., they've disappeared, that person/entity's role should be reassigned prior to the ceremony). As such, M of N would imply that you could have non-unanimity in the creation of the KSK. This strikes me as a really questionable situation to get into. Given the relative rarity of the KSK generation event, I am unclear as to why the added complexity of M of N is beneficial. Could someone explain?
To be clear, M-of-N in the VeriSign proposal applies to both KSK generation and KSK use, i.e., every time the KSK is used to sign a new root zone keyset, M-of-N authorizers need to be present. This form of M-of-N is implemented in modern HSMs and can be done today. This choice was a very conscious decision to avoid concentrating control of the KSK in any single organization. (Reading the proposal, you will note that VeriSign is not proposing to control the KSK itself.) Since root keysets can be signed in advance (e.g., generate X future ZSKs and then sign them all at once when M-of-N are present), M-of-N authorization for the KSK need not be administratively onerous. Matt
On Oct 21, 2008, at 10:34 AM, Matt Larson wrote:
This choice was a very conscious decision to avoid concentrating control of the KSK in any single organization.
That's not what I'm questioning. I don't think any proposal is putting control in any single organization. Given the importance of the KSK, the question is why would you ever want a situation where N is less than M. It seems to me that lack of unanimity of the key (part) holders would be just crazy. Regards, -drc
On Tue, 21 Oct 2008, David Conrad wrote:
On Oct 21, 2008, at 10:34 AM, Matt Larson wrote:
This choice was a very conscious decision to avoid concentrating control of the KSK in any single organization.
That's not what I'm questioning. I don't think any proposal is putting control in any single organization. Given the importance of the KSK, the question is why would you ever want a situation where N is less than M.
I think you mean "M is less than N".
It seems to me that lack of unanimity of the key (part) holders would be just crazy.
M < N allows for some parties not to be present, which might be reasonable depending on which parties make up the N. (As a practical matter, when hardware-based authorization tokens are used, M is always less than N, with additional tokens held in escrow or otherwise kept safe, so a failure can be tolerated.) Matt
On Tue, Oct 21, 2008 at 09:30:24AM -0700, David Conrad wrote:
Hi,
On Oct 21, 2008, at 4:43 AM, B C wrote:
However one point that I would strongly support from the Verisign proposal is the multi user stewardship of the KSK (the M of N principle)
Just to be clear, the KSK signing ceremony is something that happens rarely, e.g. O(years). Given the importance of the event, it would
thats the ICANN plan, plans can and do change. are there assurances that this event will remain "rare"?
role should be reassigned prior to the ceremony). As such, M of N would imply that you could have non-unanimity in the creation of the KSK. This strikes me as a really questionable situation to get into. Given the relative rarity of the KSK generation event, I am unclear as to why the added complexity of M of N is beneficial. Could someone explain?
MofN does allow for non-unanimity - but clearly is consenus driven. one could argue that distributing risk by diffusing the responsibility actually increases the stability and robustness of a system. concentration of function (collect, edit, sign, publish) does have its attractions but the potential downsides due to lack of oversight seem to be showstoppers - at least from this part of the peanut gallery
Thanks, -drc
-- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
participants (20)
-
B C -
Bill Manning -
bmanning＠vacation.karoshi.com -
David Conrad -
Dmitry Burkov -
Doug Barton -
Edward Lewis -
Florian Weimer -
Jim Reid -
Joao Damas -
Kim Davies -
Lutz Donnerhacke -
Mats.Dufberg＠teliasonera.com -
Matt Larson -
Olaf Kolkman -
Paul Wouters -
Peter Koch -
Randy Bush -
Shane Kerr -
Stephane Bortzmeyer