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