Fwd: Re: I don't trust the NZRS DNSSEC procedures... Yet
Sigh, I always forget that default reply is not to the list.
-------- Original Message --------
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Date: Wed, 08 Jun 2011 12:41:05 +1200
From: Mark Harris
Organization: Technology Research and Consultancy Services
To: Jay Daley
In any system, ours as proposed for .nz, or the TCR system for the root, collusion between multiple bad actors can lead to controls being subverted and key material stolen.
What makes this more likely than one bad actor with the whole of the key available to them? If the actors are chosen well, splitting the key reduces risk, rather than increase it. Which leads me to the point about trusting individuals to run the system. You need to publish the processes by which the people will be checked, so that the community can have trust that the individuals chosen will always be trustworthy, because untrustworthy persons won't make it through the process. Any system which is built around known individuals has already failed, when it comes to reliability. The risk is inherent.
We are more than happy to publish older versions of the DPS forever and a day, though I can't yet commit that we will make diffs available as well.
With respect, Jay, it's not rocket science to do this. Wikipedia offers a good model for displaying differing versions - just restict the authors.
Adding DNSSEC does not increase the control that NZRS has over .nz or the risks from bad actors within NZRS and so adding a TCR step for that would be disproportionate.
And yet it's not. Adding a TCR would engender trust from the community you need to trust you, so not adding a TCR will be the risk that is disproportionate. ;-) Checks and balaces, Jay. ~mark
Hi Mark On 8/06/2011, at 12:47 PM, Mark Harris wrote:
Sigh, I always forget that default reply is not to the list.
-------- Original Message -------- Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet Date: Wed, 08 Jun 2011 12:41:05 +1200 From: Mark Harris Organization: Technology Research and Consultancy Services To: Jay Daley
On 8/06/11 12:22 PM, Jay Daley wrote:
In any system, ours as proposed for .nz, or the TCR system for the root, collusion between multiple bad actors can lead to controls being subverted and key material stolen.
What makes this more likely than one bad actor with the whole of the key available to them? If the actors are chosen well, splitting the key reduces risk, rather than increase it.
My point was not that the risks of both systems are equal, just to make it clear that no system is infallible (i.e. a vulnerability in our system does not invalidate it). The balance is the appropriate thing.
Which leads me to the point about trusting individuals to run the system. You need to publish the processes by which the people will be checked, so that the community can have trust that the individuals chosen will always be trustworthy, because untrustworthy persons won't make it through the process.
Any system which is built around known individuals has already failed, when it comes to reliability. The risk is inherent.
We're more than happy to publish the processes by which people are checked, as I hoped my long response to Dean made clear. It has never been our intention to operate a "trust us" registry for all the obvious reasons.
We are more than happy to publish older versions of the DPS forever and a day, though I can't yet commit that we will make diffs available as well.
With respect, Jay, it's not rocket science to do this. Wikipedia offers a good model for displaying differing versions - just restict the authors.
Don't worry, I wasn't saying we wouldn't do it, I just wanted to check how much work was involved with our Drupal set up!
Adding DNSSEC does not increase the control that NZRS has over .nz or the risks from bad actors within NZRS and so adding a TCR step for that would be disproportionate.
And yet it's not. Adding a TCR would engender trust from the community you need to trust you, so not adding a TCR will be the risk that is disproportionate. ;-) Checks and balaces, Jay.
There are always process elements that we could add that would increase trust and the question is when to stop, when has the right balance been achieved? In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits. Can I ask - are you envisaging a TCR as an independent observer or as a partial key-holder, without whom the key generation process cannot be completed? The implications of the two are very different. cheers Jay
~mark _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 8/06/11 1:09 PM, Jay Daley wrote:
In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits. Well, I for one am not clear on the difference, so perhaps you could elaborate on what you see that as being?
On 8/06/2011, at 1:28 PM, Mark Harris wrote:
On 8/06/11 1:09 PM, Jay Daley wrote:
In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits. Well, I for one am not clear on the difference, so perhaps you could elaborate on what you see that as being?
Taken from my previous email and added to a bit: The root zone has a very different trust model from .nz: -- Every change to the root zone is independently checked by an external agency and then by the root operators before they accept it into their servers. In .nz the single registry is fully responsible for changing the zones and distributing them and serving them. -- In the root many of the participants are openly hostile, if not actually at war with each other. In NZ the participants are known to each other and have independent trust relationships. -- There is no overall regulatory framework backed up by a strong regulator for the root, which .nz does have with DNCL. -- In the root, there is no split between operations and policy, whereas in .nz this is clearly split between NZRS and DNCL. Additionally, the root does not change very often and does not have any form of SLA on how quickly those changes are made, so introducing processes that create significant operational delays is not a problem for the root. Root zone changes often take days. This contrasts strongly with .nz where we have a tight SLA that requires us to publish changes within an hour and a bit of receiving them and have metrics governing how much downtime is allowed per server, how quickly changes propagate, how quickly we serve responses, etc. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 8/06/11 1:39 PM, Jay Daley wrote:
Taken from my previous email and added to a bit: The root zone has a very different trust model from .nz: -- Every change to the root zone is independently checked by an external agency and then by the root operators before they accept it into their servers. In .nz the single registry is fully responsible for changing the zones and distributing them and serving them. -- In the root many of the participants are openly hostile, if not actually at war with each other. In NZ the participants are known to each other and have independent trust relationships. -- There is no overall regulatory framework backed up by a strong regulator for the root, which .nz does have with DNCL. -- In the root, there is no split between operations and policy, whereas in .nz this is clearly split between NZRS and DNCL.
Additionally, the root does not change very often and does not have any form of SLA on how quickly those changes are made, so introducing processes that create significant operational delays is not a problem for the root. Root zone changes often take days. This contrasts strongly with .nz where we have a tight SLA that requires us to publish changes within an hour and a bit of receiving them and have metrics governing how much downtime is allowed per server, how quickly changes propagate, how quickly we serve responses, etc.
Sorry, you're talking processes, not models. You can set up the process to be as efficient as you need it to be - that doesn't change the model. But if you're talking about "how much trust can we afford?", I think you'll find little traction here, given the history of this gTLD, NZRS and InternetNZ. Because I see that as "how little trust can we get away with having to pay for?" ~mark
participants (2)
-
Jay Daley
-
Mark Harris