Hi Dean Thanks for raising these concerns. This sort of feedback is invaluable to us and it is good that you have taken the time to look through our documents. Below are answers to your concerns, which I hope are sufficient, but if not we are more than willing to discuss further and reconsider our plans before DNSSEC goes live. I think I can fairly summarise your concerns into the following key points: 1. Key length 2. Document management / notifications 3. Site security 4. Audit 5. Personnel 6. Trusted community representatives If I go through each of these individually: 1. Key length The decision on key length takes into account a number of factors: - The time/CPU needed to generate the signatures - The size of the signatures being generated (and the corresponding DNS packet). During rollovers, when an extra key is present, you are more sensitive to problems with packet fragmentation and TCP retries. - The intended lifetime of the key - The effort required to break the key Our chosen key size of 1280 is generally recognised as a good key length to use for keys with a 1 year lifetime as it balances these factors well. If we were planning to keep the keys for longer then a longer key size would be appropriate. What's not shown on your table of other registries is the intended lifetime of their keys and it is because many of them want keys to live for a number of years that they have chosen to use a longer key size of 2048. As far as we can tell you have based your comments on the original text present in RFC 4641, dated on September 2006. A new version, RFC 4641bis is very close to be published and we actively participated as reviewers (you can find Sebastian's name in the bottom) and that radically revises key length recommendations based on significant input from cryptographers. Some early adopter registries may have made their choices based on the earlier version. 2. Document management / notifications 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. There is a notification policy and we will amend the DPS to make that clearer. It is also our intention to send update notifications to NZNOG but we haven't committed to that in the DPS in case there is a kickback at us spamming the list. We do also provide a separate list for technical announcements that we will send notifications to, which is for those that prefer separate lists. 3. Site security There is a trade off between us being transparent and us taking reasonable precautions to protect our systems. It is our view that publishing a list of our sites and the security controls in place in each one is imprudent and it is better that we are not transparent on that point. We could publish a list of general controls (locked cabinets, etc) that we use, if that would be helpful? 4. Audit This is a general area that we targetting with an aim to be far more transparent on this in future. Currently we employ external security assessors each year to carry out - penetration testing - procedural compliance - security culture evaluation and audit - internal security control evaluation and audit (including DNSSEC) - end to end threat modelling It is our intention to be able to share some of the results of these audits over time but we are naturally cautious so as not to unnecessarily expose information that might help an attacker. For the DNSSEC key signing we will publishing the Key Generation script and the execution log. 5. Personnel We are happy to look at increasing the published information on the background checks that we do of staff and to increase those checks. This may take some time for us to document what we do and take advice on what further checks are legal but we will address it. 6. Trusted community representatives A simplified trust model for DNS looks like this: 1. Registrant sends their DNS details to the Registrar. a. Registrant trusts the Registrar to accept those faithfully b. Registrar trusts that it is the Registrant they are dealing with 2. Registrar send these details on to the Registry a. Registrar trusts the Registry to accept those faithfully b. Registry trusts the Registrar to be sending the Registrant details faithfully 3. Registry builds the zones a. Everyone trusts Registry to include Registrant details faithfully b. Everyone trusts Registry to build zone correctly 4. End User/ISP queries the zone a. End User/ISP trusts that the zone has been served correctly b. End User/ISP trusts that the data they received is what was sent Using a similar diagram to yours, we can show the strength of assurance in each link of the chain as follows (for those involving the registry) 2a. * * * * * 2b. * * * * * 3a. * * * * * 3b. * * * * * 4a. * * * * * 4b. * * DNSSEC is specifically intended to address the weaknesses in 4b by providing cryptographic signatures on the data sent. By doing this it adds another step: 3c. Everyone trusts Registry to add signatures correctly However, what it does not change is 3a or 3b, which is where the Registry could still make changes if it wished. The new strength of assurance is as follows: 2a. * * * * * 2b. * * * * * 3a. * * * * * 3b. * * * * * 3c. * * * * * * * * * * * 4a. * * * * * 4b. * * * * * * * * * * * What you are proposing with TCRs and key ceremonies (and key length of 2048) would change it to: 2a. * * * * * 2b. * * * * * 3a. * * * * * 3b. * * * * * 3c. * * * * * * * * * * * * * * * * * * * * * 4a. * * * * * 4b. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Any chain is only as strong as its weakest link and so pushing up the trust of 3c and 4b does not add to the overall strength of this chain of trust. It is important to recognise that .nz (and other TLDs) are very different from the root. The concept of TCRs is not being adopted by most TLDs and is likely to remain a feature largely unique to root signing. 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. -- Many of the participants are openly hostile, if not actually at war with each other, -- There is no overall regulatory framework backed up by a strong regulator, which .nz does have with 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. So to summarise on TCRs: 1. 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. 2. The strength of trust proposed for the individual links in the chain is proportionate given the overall trust model. 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 7/06/2011, at 8:33 PM, Dean Pemberton wrote:
Hi All,
(TLDR warning - If you're not going to read this long post then you can skip to the *TLDR Breakpoint* near the end)
Trust is a funny thing. It's one of those qualities which is up to an individual to freely give rather than for someone else to demand that it be given. Recently NZRS published their DNSSEC Practice Statement (DPS) to this mailing list and asked us as a community to trust both them and these procedures.
But more than that, they have asked us to trust that these procedures would work in the years to come. Even if all the people we know at NZRS have left, we should still be able to trust that these procedures will yield a trustworthy DNSSEC model for the .nz ccTLD
And I'm afraid that at the moment, with the current document, I'm in the uncomfortable position of not being able to advise my clients to place any significant level of trust in the current procedures.
So where are the problems?
For me, being able to evaluate whether I can give this system a tick or a cross, comes down to three areas.
The theory that the system is designed around. The people operating the system. The procedures they are following.
Get a tick for all of those, and we're all good. Get a cross for any one of those and it still needs work.
THEORY: The theory behind this implementation of DNSSEC is sound. NZRS has followed the designs of some giants in the field and I believe they have this right, so THEORY is well on the way to getting a tick.
My only concern at this level is a relativity low keysize that has been chosen.
NZRS has decided on 1280 as a key length for the KSK. 2048 seems to be a much wider accepted standard. In fact RFC4641 recommends 2048 as a KSK key length for 'high-value' domains such as TLDs.
Of the following list of DNSSEC enabled domains only one has chosen 1280 as a KSK length.
root 2048 br 1280 se 2048 cz 2048 uk 2048 org 2048 gov 2048 edu 2048 kirei.se 2048
NZRS must have reasons and I'm all ears, but in the mean time, organisations I've spoken to have refused to give this a tick of trust based on the low key length.
PEOPLE: It's not even with the current people concerned. Both Jay and Sebastian are great upstanding people and individually worthy of trust, but as far as I know they are not going to be the only ones with access to the key material. They are certainly not going to be the only ones with access in the future. I believe that the current procedures are lacking when it comes to proving to you and me that the people with a level of authority in this system are worthy of trust.
Reading the DPS document, the key material is protected by two NZRS employees (or board members) who have had 'standard pre-employment checks'. I'm sorry but that falls below what I need in order to be able to recommend that organisations start to trust this system.
Given that we live in a world of Advanced Persistent Threats, this system needs to be safe on a level far above two people, who may even report to the same manager, and nominated friendly people on their CV.
Other domains who have implemented DNSSEC, have stated that they will perform financial background checks on trusted individuals, or even checks for previous criminal convictions. Some other domains have even gone to far as to say "We don't even want to be the *only* trusted party. We're going to require other participants to be present". Our very own Andy Linton is one of these Trusted Community Representatives for the root zone.
Without these kinds of safeguards, there is nothing to say that in 12 months, when there have been employment changes at NZRS, two of the admins won't feel like selling the key material to the highest bidder (and I have no trouble imagining that it's worth a lot of money).
Once again, I'm not saying that the people involved today are untrustworthy, but how will we know that the next person is just as trustworthy? What are the procedures in place to make sure of that?
If NZRS widened the group of participants to include Trusted Community Representatives, they would be well on the way to a tick here.
PROCEDURES:
I believe that there are some areas where the procedures don't meet my bar for being able to trust the system.
The highlights are.
. No stated archive of old versions of the document. The entire document could change over time and it might not be possible to see when this was done. . No information around the security aspects of the co-location sites. Other DPS documents have outlined the security features used and who has access. . No elaboration on who has access to the equipment. Do co-location staff have access as well as NZRS staff. If not, how is this enforced and audited? . Vulnerabilities are assessed by looking at logs and assessing of there has been a problem. Some more proactive assessment might be worthwhile here. . Why is there no regular schedule for an external audit? ICANN has set regular audit dates (two years I believe without looking it up). Leaving it up to NZRS to have them 'as necessary' means that they could never be done at all.
There are some others as well but you can see where I'm going here.
The obvious question I ask myself here is: "Dean, are you being an unreasonable git?"
Well I don't think so. When the root was signed they got this all correct in my opinion. They got the community on board and have a level of trust in their Theory, People and Procedures which I think is unparalleled at this time. Now I don't expect NZRS to implement the .nz system to the same level, but I do expect it to be just about as high. Looking through the DPS documents of some of the other DNSSEC enabled domains, they get more ticks that we currently do. So I don't think I'm being unreasonable here.
I also don't want to create a trust-valley for the .nz ccTLD. The DNC and NZRS have done some great work promoting .nz as a place that people want to host their domains. I don't want it to become a trust-ghetto.
It's widely accepted that the root zone got the level of trust right and that it's probably a 10/10. Lets imagine that you're an NZ bank or an NZ government department.
You implement your DNSSEC procedures using the same sort of procedures which you currently use for other PKI and get about an 7/10 on the trust scale for your blah.govt.nz domain. You then look at the .nz ccTLD procedures and only give them a 5/10.
The problem now is that no matter how much you trust your system, or the root zone, there is always this valley of trust in the middle which is eroding the whole system back to a 5/10.
10| * 9| * 8| * t 7| * * r 6| * * u 5| * * * s 4| * * * t 3| * * * 2| * * * 1|___*_______*__________*________ root .nz blah.govt.nz
Now lets imagine that you trust some other domain an 8/10.
10| * 9| * 8| * * t 7| * * * r 6| * * * u 5| * * * s 4| * * * t 3| * * * 2| * * * 1|___*_______*__________*________ root .com blah.com
Where do you think people are going to buy domains they want to be secure? Not in the trust-ghetto I can assure you of that.
So I'm putting my bar at about an 8 or a 9 for the .nz ccTLD. Any lower than that and it's no use to organisations who want to implement high-assurance DNSSEC themselves.
*TLDR Breakpoint*
So where to from here? Well I think it's totally fixable. As I mentioned before, I think we currently have the right people currently at NZRS to address this. But what I'd like to see is much less of the:
"Trust us, we know what we're doing"
And much more of:
"Here is exactly what we're doing. You tell us if we've got your trust yet."
So lets start to address some of these issues. If you think I've got it wrong, than by all means chime in. If you think there are other areas which need work then chime in. If we get this right then I'm going to be the biggest .nz DNSSEC advocate and tell everyone who will listen that .nz is the place to host domains you want to secure.
Otherwise I'll just buy more non .nz names and advise others to do the same.
Regards, Dean
_______________________________________________ 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