I promised to come back to the list with more details on two elements of our DNSSEC Practice Statement, which has taken a bit of time for research and other reasons. First, for those of you who have not had the time to get up to speed on DNSSEC I've written a brief introductory article on it for NZCS: http://www.nzcs.org.nz/newsletter/article/141 We will endeavour to put more articles up on our web site, but until then we publish our presentations on DNSSEC here: http://nzrs.net.nz/dns/dnssec If there are any specific resources that you would like us to consider publishing then please let me know. Next we come to the research Sebastian has conducted. The results of this are: - Of the 75 top level domains that have DNSSEC only 10 publish a DNSSEC Practice Statement like us. - Of those 10, none publish site locations. - Of those 10, none use trusted community representatives (TCRs) and we know of none from the other 65 that do. It seems clear that all other TLDs agree with us that what is in place for the root is inappropriate for a TLD. As we have agreed to change our key size to that used by the majority of other TLDs we are now fully in line with best practice as used by other DNSSEC signed TLDs. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
As we have agreed to change our key size to that used by the majority of other TLDs we are now fully in line with best practice as used by other DNSSEC signed TLDs. Frankly, I am disappointed with this response and I believe you all should be too. I think the NZNOG community deserves better than to be told. "No one else has answered these questions, so we're not going to either". Ever consider that they weren't asked of any other TLD? New Zealand, and NZNOG in particular, has always prided itself as having a
On 20/06/11 3:08 PM, Jay Daley wrote: particularly vocal and motivated technical community. How many overseas speakers do we get at conferences who rave about how unique the NZNOG community is? If every organisation behaved as NZRS just has, then back in 2003 we'd have been told that because no other ccTLD had a .geek subdomain so the .nz ccTLD wasn't going to have one either. The DNC wasn't that close-minded however and the .nz ccTLD is a better place for it. Once again rather than taking the opportunity to engage with the community and provide clarity, NZRS has spent time and resources to justify why it should not have to provide any additional information. Aside from that, the NZRS DPS is not "fully in line with the best practice as used by other DNSSEC signed TLDs", and I'll show you why. NZRS hasn't done you any favours here, they have made it hard for you to assess how they stack up with others around the world by not actually linking to the other TLDs (or even providing their domain names). I'll show how some of the other registries handle these issues, but really... It's not about doing the bare minimum and then claiming that you're compliant, it's about building trust within your own community, answering their concerns, so that they will trust and accept your suggested processes. Something which I don't believe NZRS is doing very well at present. Here are links to some of the other TLD DPS documents. .se http://www.iis.*se*/docs/*se*-*dnssec*-dps-eng.pdf .jp https://jprs.jp/doc/dnssec/jp-dps-eng.html .com, .net, .edu http://www.google.co.nz/search?q=verisign+DNSSEC+practice+statement (top 3 links) .nl https://www.sidn.nl/fileadmin/docs/PDF-files_UK/DNSSEC%20Policy%20and%20Prac... I'd like to start off by drawing attention to the following passage from the NZRS DPS: "With the support of this DPS, the relying party can determine the level of trust they may assign to DNSSEC in the .nz domain and assess their own risk." I like the way that RIPE NCC words this better (http://www.ripe.net/data-tools/dns/dnssec/dnssec-policy-and-practice-stateme...): "The purpose of this document is to enable stakeholders to determine the level of trust they wish to grant to the RIPE NCC DNSSEC management." The DPS document is meant to provide you, the stakeholder, with all the information you need to be able to assess how much you'll trust the DNSSEC system. I'd cover one area (Physical Security) in this email, but I believe the argument holds for other areas within the DPS as well. What is the sum total of the information that NZRS gives stakeholders about the security of the physical environment protecting the .nz key material? "All facilities have restricted access, limited to authorised personnel and proper access logs." If I try and use this information to determine a level of trust, it's very difficult because it's so.... sparse. The problem is that there are lots of ways in which NZRS could implement the physical security of the system and still be compliant. A locked door and a logbook outside a spare room at the NZRS offices would satisfy all the physical security requirements of the .nz DNSSEC system. There are other bullet points in the DPS about aircon, UPS, generator, fire system, smoke detectors, but they don't guarantee that the location is any more secure than a standard office environment. See why it's hard to establish trust from a statement that general? Now I'm not saying that's where they are deploying, but there is nothing to stop present or future NZRS management from doing so. What's more, because NZRS refuse to disclose the location of the equipment, they wouldn't even need to tell the community if it was moved so such a location. So if NZRS really is "fully in line with the best practice", you'd expect all the other DPS documents to give the same sparse information, right? Well, lets see what information the other TLDs choose to give their stakeholders.. Verisign who manage the .com, .net and .edu TLDs have a DPS which states: "4.1.1 Site location and construction Verisign DNSSEC operations are conducted within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems, whether covert or overt. Verisign also maintains disaster recovery facilities for its DNSSEC operations. Verisign's disaster recovery facilities are protected by multiple tiers of physical security comparable to those of Verisign's primary facility. 4.1.2. Physical access Verisign DNSSEC systems are protected by a minimum of four tiers of physical security, with access to the lower tier required before gaining access to the higher tier. Progressively restrictive physical access privileges control access to each tier. Sensitive DNSSEC operational activity, any activity related to the lifecycle of the COM KSK & ZSK, occurs within very restrictive physical tiers. Access to each tier requires the use of a proximity card employee badge. Physical access is automatically logged and video recorded. Additional tiers enforce individual access control through the use of two factor authentication including biometrics. The physical security system includes additional tiers for key management security which serves to protect both online and offline storage of HSMs and keying material. Areas used to create and store cryptographic material enforce dual control, each through the use of two factor authentication including biometrics. Online HSMs are protected through the use of locked cabinets. Offline HSMs are protected through the use of locked safes, cabinets and containers. Access to HSMs and keying material is restricted in accordance with Verisign's segregation of duties" Now to me, I'm much more able to read that information and use it to decide how much I'm going to trust their physical security. You don't have to be that wordy though. There are other TLDs which err on the sparse side but still manage to provide more information than NZRS. The .se DPS contains a very important addition: "All of the systems components are protected within a physical perimeter with an access control and alarm system operated by .SE." By reading the NZRS DNS it's not clear that there even IS an alarm system in place around the .nz key material, let alone who it's controlled by. As an aside, if you'd like to see some photos of some components of the .se system they are available in this tutorial http://www.iis.*se*/docs/*dnssec*_20090529_*tutorial*-dps.pdf The organisation operating the .nl ccTLD aren't afraid to admit where one of their locations is, and they do at least state that the other ones are data centres: "Site location and construction SIDN operates multiple sites in the Netherlands. These include server-rooms in the SIDN office, cabinets in multiple geographically dispersed data centres and a backup site outside of Arnhem." Another aside, if you'd like to see some pictures from the .NL folks, have a look at this presentation: https://www.os3.nl/_media/2010-2011/uva-20101019.pdf. Great pics of the signing ceremony as well as the hardware tokens and HSM. Again, the more information, the more you can evaluate trust in the system. Even the English translation of the .jp DPS has additional information over the NZRS version: "4.1.2. Physical access With regard to the Important Facility Room, the Registry controls entry and exit from the room by conducting the identification of relevant person and checking of the entry permission. The Registry does not permit person who has no entry permission to enter the room. If entry of such person is unavoidable, the person will be allowed to enter by receiving one-time entry permission beforehand and accompanied by person who has entry permission." So the room access is atleast controlled by the Registry. Well that's an assurance we don't have from NZRS, it could be controlled by a third party. In fact we don't even have an assurance that there is a dedicated room/physical perimeter. The NZRS equipment could be housed in a shared environment with other colo customers' equipment. Other colo customers would indeed be be authorised to access the shared environment and might even have physical access to the NZRS systems. I'd certainly like to know this when making a decision about how much to trust the system. The .JP DPS also explains that unauthorised persons (think the IBM/Oracle/HP hardware tech swapping a motherboard) are escorted. It's another assurance we don't have from NZRS (unless I'm missing it somewhere else in the document). So in summary, I don't believe that NZRS can say they are "now fully in line with the best practice as used by other DNSSEC signed TLDs" by just making a single change to the key size. As people have pointed out, even using an xkcd cartoon, keysize is only one area, and not even the easiest one to compromise. Getting the rest of this right is just as important. Other TLDs go further (some, like Verisign go MUCH further) to give their stakeholders more information about physical security to enable them to make informed trust decisions. This information sharing to allow stakeholders to determine a level of trust is something that the architects of the DPS system intended. All the information that NZRS prepared to give the .nz stakeholder community is: "All facilities have restricted access, limited to authorised personnel and proper access logs." I'm not prepared to say that I trust a system when that's the only information I have about it. That's just one area. There are other sections in the other TLD DPSs which are much more informative than the NZRS DPS (Personnel Checks are one which stands out). I'd like to suggest that NZRS is a little more descriptive in the areas around Physical Security. Even if you were to take all the bits from the other TLDs and glue them into one paragraph is would be better than what we have right now. "All facilities have restricted access, limited to authorised personnel. and proper access logs. These include server-rooms in the XXX offices, cabinets in two data centres, and a backup site outside of XXX. All of the systems components are protected within a physical perimeter with an access control and alarm system operated by NZRS. If entry of unauthorised personnel is unavoidable, the person will be allowed to enter by receiving one-time entry permission beforehand and accompanied by person who has entry permission." Regards, Dean
Hi Dean On 22/06/2011, at 11:47 PM, Dean Pemberton wrote:
I'd like to suggest that NZRS is a little more descriptive in the areas around Physical Security. Even if you were to take all the bits from the other TLDs and glue them into one paragraph is would be better than what we have right now.
"All facilities have restricted access, limited to authorised personnel. and proper access logs. These include server-rooms in the XXX offices, cabinets in two data centres, and a backup site outside of XXX. All of the systems components are protected within a physical perimeter with an access control and alarm system operated by NZRS. If entry of unauthorised personnel is unavoidable, the person will be allowed to enter by receiving one-time entry permission beforehand and accompanied by person who has entry permission."
The new level of detail you propose seems quite reasonable to us and we are happy to incorporate that level of detail into the DPS. thanks for the contribution Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
Hi all Just to follow up on this - we aim to have a new version of our DPS ready to discuss by the end of next week. To summarise discussions so far, it will have - Document management (notifications are handled by the new list we set up). - More details on site security using the most recent example from Dean as a guide. That won't give the addresses of the sites but it will give their cities and suburbs. - More details on our audit processes including what we audit and how frequently we audit. We do want to commit to publishing the results but not until we have some processes in place around that, which may not be in time for the DPS or even the launch of DNSSEC. - Different key sizes and M of N key splitting amongst NZRS staff and greater explanation of what that means for security of key backups. - More details on the staff vetting. This bit may be light to start with and change again later when we have received more detailed advice on what we can do in this regard. regards Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
Hi Jay, I think that's a great idea. Look forward to that.
- Document management (notifications are handled by the new list we set up).
Cool
- More details on site security using the most recent example from Dean as a guide. That won't give the addresses of the sites but it will give their cities and suburbs.
Yep - happy with that. All in all, it's about giving a little more detail of how things are protected, but not necessarily the specifics. Eg, Access control system managed by NZRS. Rather than.. A Cardax version 3035 access control system with keypanels located.....
- More details on our audit processes including what we audit and how frequently we audit. We do want to commit to publishing the results but not until we have some processes in place around that, which may not be in time for the DPS or even the launch of DNSSEC. Yep - happy to work with that commitment. - Different key sizes and M of N key splitting amongst NZRS staff and greater explanation of what that means for security of key backups.
Looking forward to seeing that, but sounds good.
- More details on the staff vetting. This bit may be light to start with and change again later when we have received more detailed advice on what we can do in this regard.
Ahh yep, I understand why you might need to get some advice on this. In the short term it might fill a gap if you detail what the *intent* of the vetting is and then fill in the details later. For example, If you can't put down Criminal Background Check on day one, then a statement along the lines of "NZRS intends to only provide trusted positions to staff with no criminal convictions regarding trust based crimes. At present NZRS is investigating how this will be accomplished." similarly. If you don't want to commit to Financial Background Checks on day one, a statement like "NZRS intends to provide trusted positions to staff who..... blah. At present NZRS is investigating how this might be accomplished." I'm comfortable that you might not have all the answers yet, but it helps me out heaps to know that it's your intention to find them out. Also wanted to say thanks for all the hard work that you and the NZRS staff are putting into this. It's starting to look like it's coming together. Regards, Dean
Hi everyone, To add to Jay's post, one other DPS item that we noted feed back from the community about, and are working on, was the Key Pair Generation section of the document. It is our intention to improve that part of the DPS too and to also publish more technical details on the Key Pair Generation Procedure. This will be released as a separate document that will also include details of the scripts used. We are still working on testing the Key Pair Generation Procedure but hope to produce an outline of the technical details on the Key Pair Generation Procedure soon after the new version of the DPS is published. Regards Dave On 24/06/2011, at 3:31 PM, Jay Daley wrote:
Hi all
Just to follow up on this - we aim to have a new version of our DPS ready to discuss by the end of next week. To summarise discussions so far, it will have
- Document management (notifications are handled by the new list we set up).
- More details on site security using the most recent example from Dean as a guide. That won't give the addresses of the sites but it will give their cities and suburbs.
- More details on our audit processes including what we audit and how frequently we audit. We do want to commit to publishing the results but not until we have some processes in place around that, which may not be in time for the DPS or even the launch of DNSSEC.
- Different key sizes and M of N key splitting amongst NZRS staff and greater explanation of what that means for security of key backups.
- More details on the staff vetting. This bit may be light to start with and change again later when we have received more detailed advice on what we can do in this regard.
regards Jay
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Dave Baker Chief Technology Officer .nz Registry Services (New Zealand Domain Name Registry Limited) e dave(a)nzrs.net.nz m 64 21 515 677 p 64 4 931 6978
participants (3)
-
Dave Baker
-
Dean Pemberton
-
Jay Daley