On 8/06/2011, at 9:11 PM, Dean Pemberton wrote:
It's nice to get some responses to these concerns. As you can no doubt see by the responses you've received today, I'm not alone in these views.
Thanks again for you're involvement and while we have heard from a couple that agree with you I would still be very interested in hearing from others, one way or another.
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
Agree with all of these, but that doesn't stop a significant number of other DNSSEC adopters from choosing 2048 keys and making it work.
You might have a really good reason to choose 1280 bit, but as it's a departure from what others have done, you're going to need to go the extra mile to convince people they can trust this.
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.
I can see what you're presenting here, but could you provide examples of who 'generally recognises' that 1280 is a good key length? Again this goes to the fact that it's a new concept to many people and needs to have it's credibility established. The domains of these adopters should be enough.
One of the quickest ways for me to destroy trust in NZRS would be to answer the question "Why have you chosen a 2048 bit key?" with the response "Because that is what most of the other TLDs do.". Any choice one way or the other needs a rational and evidenced explanation.
RFC4641bis doesn't mention a keysize of 1280 as far as I can see. Infact it says:
Depending on local policy (e.g. owners of keys that are used as extremely high value trust anchors, or non-anchor keys that may be difficult to roll over), you may want to use lengths longer than 1024 bits. Typically, the next larger key size used is 2048 bits.
I would say that the .nz domain was an extremely high value trust anchor, wouldn't you?
Yes, which is why we are not using 1024 bit keys for KSKs, which is what that text is clearly talking about. To recap and add some more detail, our explanation for choosing 1280 is: 1. The keys will only be used for one year and not many years as other registries are doing. 2. The keys are only used for signing and not encrypting, which increase the acceptable lifetime of keys. 3. Recommendations by standards bodies in this area come into two categories, those that deal only in multiples of 1Kb and those that deal with fractional sizes. For the latter the main equations are those produced by Professor Lenstra in http://www.keylength.com/biblio/Handbook_of_Information_Security_-_Keylength.... Using those guidelines, a key length of 1280 to *encrypt* something now can be conservatively expected to remain secure until 2014 and optimistically until 2017 (p26). If you use the standards that only deal with 1Kb multiples then they will recommend 2048 as lasting ten years but will not comment on 1280 bit keys. 4. We do not want to push the key size up to 2048 "just to be sure" because that imposes a greater DNS packet size and CPU cost for signature verification for end users of DNSSEC. We are also acutely aware that a TLD registry often sets a de facto standard followed by their registrars and registrants, which magnifies the impact of our choice. If you are serious in proposing 2048 bit keys as alternative policy then can you provide a similar explanation to allow the community to judge the two? I will respond to the rest of your points later! cheers Jay
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.
6. Trusted community representatives
[Jump to later emails on this subject]
Andy Linton writes:
I think we need to look at this more closely.
.nz does not change very often - the zones that change often are co.nz, net.nz etc. So we may have different requirements for those levels. I can envisage govt.nz or mil.nz having different trust requirements from org.nz or geek.nz for example. We haven't delegated those zones in the past but it's possible that might happen. We're lumping .nz and the second level domains together and that may or may not be appropriate.
I also think that we should be willing to consider changes in the performance characteristics of the system if it makes it more secure. I would certainly be willing to raise a modified SLA with the DNCL Board.
I think that Andy is onto something here. There are different requirements for .nz than .govt.nz than .geek.nz.
For example I can imagine the moderators of the moderated second level domains wanting to have some involvement here.
Mark Harris writes:
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?"
I was going to invoke Godwin's law on the first person to bring up that portion of history, but I think Mark does it well.
Lets not do something less trustworthy because it's easy, lets do what's right.
Jay Daley writes:
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.
Well I think that's a good effort for 24 hours.
Some of these issues seem well on the way to being sorted.
. Document Management . Audit . Personnel
Some need more explanation:
. Key Length
Some other ones don't seem to have moved anywhere yet:
. Trusted community representatives . Site Security
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