Hope everyone had a good weekend. On 9/06/11 1:10 PM, Jay Daley wrote:
I will respond to the rest of your points later!
Thanks Jay. As pointed out earlier we can't just focus on key size, the other points are in some ways more important. I've updated where we left off below
2. Document management / notifications
It looks like we have agreement here. Put something in place and this gets a tick from me.
I'm happy to say that you can post to NZNOG (although Donald has already said as much as well). It's much less noise than the routing updates.
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?
Hmmm lets split this in two.
1) It would be great if you published a list of general controls, I think that would be heading in the right direction. 2) As for needing to keep locations and security controls secret. I don't agree, not for one second. You only need to look at the root to see that this isn't required to be able to implement this effectively. How is it that they are able to go into a resonable level of detail about the 7 tiers they have and still maintain security, when NZRS is not able to utter a word about where their colo is without compromising their security model then alarm bells are sounding pretty loudly for me. Here's what ICANN is willing to say about the system which secures the root zone... The KSKs will be maintained inside 24x7 manned secure data centers behind multiple tiers of access control. Tiers 1-2 represent various access controls (guard, man- trap, biometrics, etc.) associated with the general secure data center population. Tier 3 and above are controlled by ICANN. Tier 4 represents the key ceremony room and requires multi-factor access control and escort by at least two (2) specifically designated ICANN staff, typically the Ceremony Administrator and Internal Witness. Tier 4 is where HSM initialization, key generation, KSR signing, and key destruction will take place. No equipment executing cryptographic operations will be stored here. Certain data center staff may have access to tier 3 for inspection purposes. Tiers 4 and above cannot be accessed by data center staff except in an emergency and without triggering alarms. All entry and exit into Tiers 1-2 will be logged by the data center. Tiers 3-6 will be logged by the ICANN retained monitoring company. Tier 5 cannot be accessed by data center staff and requires two (2) specifically designated ICANN staff. This tier contains two GSA Class 5 safes forming Tier 6. Combinations to each safe are held by two distinct, specifically designated ICANN staff members who are different from the Ceremony Administrator and Internal Witness. Safe #1 contains key management software, laptops and the HSMs containing the KSKs. The HSM represents Tier 7 for private key access. There are at least two (2) HSMs per site holding duplicate key and configurations for backup purposes. HSMs are regularly replaced (destroyed and reinitialized) every five (5) years to ensure functionality and battery life. Safe #2 contains ten (10) safe deposit boxes (Tier 7) containing the crypto officer smart cards (in tamper evident packaging) needed to activate the HSM. The crypto officers hold the keys to the safe deposit boxes, which adds a layer of protection for the crypto officers from coercion and to the overall system from lost activation data and collusion. PHEW!!!! Now remember, I'm not saying that you need to go out and buy Class 5 safes and Man traps, but see how much information ICANN is willing to let out? Sure this has some impact on their OPSec, but the trust they get from it is worth the small impact. They are even willing to post where they are housed ICANN East Coast Facility c/o Terremark NCR 18155 Technology Drive, Culpeper, VA 22701-3805 ICANN West Coast Facility c/o Equinix LA3 1920 East Maple Avenue, El Segundo, CA, 90245 I'm interested in how they can do that, and NZRS can't utter a word without all the security coming apart like a badly knitted jersey. I agree that it's a trade off, but I don't think NZRS has it right here. This is still a no trust area.
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
Wow - you know that sounds AWESOME. Now why didn't your DPS actually say any of that. If you place those bullet points into the document, with any relevant standards which would need to be met (ie pen testers must be certified when that comes in etc), then it's starting to look really good.
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.
I'm going to sub-contract my trust assessment here. I trust NZITF (New Zealand Internet Task Force) to be able to assess if this is being done to a satisfactory level. Convince them that you've got this right and that's good enough for me.
For the DNSSEC key signing we will publishing the Key Generation script and the execution log.
That's awesome. Doc should state that.
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.
Cool - happy with that direction. I'd suggest talking to some of the banks (again NZITF could help here) as well the ususal suspects in govt.
There is plenty that could be done here, and given that much of what you do is considered critical infrastructure, it should be made available to you. Add financial checks and a criminal record check and I'm pretty happy. Find a department to sponsor your trusted staff a higher security clearance and I'm done here. As Michael points out though, there is as much at risk due to people following the procedures. I recently tried to get some more information about these but the response said "They are not ready for production yet". Happy to wait until you release them to comment, but isn't that how we ended up producing a huge 'no-trust' thread. It might be better to get drafts out while they are being worked on rather than in their finished form.
6. Trusted community representatives
Sebastian made reference to an "External Witness" in one of his emails. This wasn't referenced at all in the DPS. Could you clarify under which situations an External Witness is included and what they are expected to do?
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. I agree, they are different. As a compromise, could we agree to have one or more TCRs as External Witnesses initially, and them work out what's actually so hard about the M-of-N keyholding part later? Remembering that long term this may only be for the .nz zone and moderated domains rather than all the lower levels.