I don't trust the NZRS DNSSEC procedures... Yet
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Evening All Dean had kindly shared his concerns with us earlier and I suggested that he take his concerns on-list rather than us discuss them privately as it is important for us in NZRS to understand the community views on our DNSSEC plans. We can of course explain all of our choices but I would rather not do that for a while so that we don't prevent a conversation from developing. cheers Jay 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
![](https://secure.gravatar.com/avatar/693c3a8192ac841ff4d42d469f2ff161.jpg?s=120&d=mm&r=g)
Here's an easy one:
. 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.
It looks to me like the document is authored in Word or OpenOffice, then PDFs published to the website. The policy document should be entered into a document management system or code repository. The community should be able to do diffs all the way back to version 0.1. -JB -- ------------------------------------- +64 27 502 8230 http://about.me/jonbrewer -------------------------------------
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
Yep - that ticks the box as far as I'm concerned. Have a URL referenced in the document where you can access all the version history. Next... Regards, Dean On 7/06/11 9:31 PM, Jonathan Brewer wrote:
It looks to me like the document is authored in Word or OpenOffice, then PDFs published to the website. The policy document should be entered into a document management system or code repository. The community should be able to do diffs all the way back to version 0.1.
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
On 7/06/2011 9:31 p.m., Jonathan Brewer wrote:
Here's an easy one:
> . 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.
It looks to me like the document is authored in Word or OpenOffice, then PDFs published to the website. The policy document should be entered into a document management system or code repository. The community should be able to do diffs all the way back to version 0.1.
Should there also be a policy of change notifications? Should document changes be sent to this mailing list as an archive? ...and in a plain text format so that interested parties can perform diffs quickly? In suggesting this I considered, Q: Do you want the Network Operators List to be used as an archive? A: Yes. The list goes out to many known and unknown parties with off line systems that are not controlled by NZRS, so we can be assured that the historic information can't be tampered with and many parties can archive and compare the content if need arises. Q: Why not just create a NZRS list for such change announcements? A: I'm on dozens of lists and some of them eventually go to /dev/null Some things need to come to industry as a whole without the need to subscribe to every list under the sun. However I also agree that I don't want every 'seemingly important' thing thrown at me each day on this list either, and I'm sure there are many many others who are much more busy that I am. How important is this DNSSEC stuff to the community? - I can't answer that alone, we have to answer that one individually as a community. D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 www.thinkdesignprint.co.nz
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
On 7/06/2011 9:11 p.m., Jay Daley wrote:
it is important for us in NZRS to understand the community views on our DNSSEC plans.
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions - I confess I haven't even gone as far as reading the wikipedia page to gain a vague understanding of what DNSSEC is, other than already understanding it's a security system for enhancing confidence that the web site you're looking at is actually just that. A decade ago Geoff Huston wrote an article about the internet being a trust domain which stuck with me, so I get some of where Dean is coming from. So, if the issue is trust and confidence and then I see Dean openly questioning the system then I'm left thinking.... Dean is a person I respect for his technical ability, so if he doesn't yet trust this new system then that tells me it's currently valueless. So what recommendation would I give to a client or associate (for what that's worth) "Well Dean doesn't currently trust it, I couldn't recommend putting to much investment in it until I at a very least see him express his confidence in the system". Make of those views what you will :) D
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
Cheers Jay, On the contrary, I'd love to prevent a conversation from developing. I'd like nothing more than to hear the explanations, have them documented where appropriate, and move this whole situation to the "Been there, done that" pile. If the next post in this thread had all the explanations, I'd reply with "I fully trust the NZRS DNSSEC procedures" and go back to being a .nz advocate. Why make people read/write untold posts while they wait for explanations which are available now. I don't see the reason for all the secrecy. It does nothing to foster trust in the community. Regards, Dean On 7/06/11 9:11 PM, Jay Daley wrote:
Evening All
Dean had kindly shared his concerns with us earlier and I suggested that he take his concerns on-list rather than us discuss them privately as it is important for us in NZRS to understand the community views on our DNSSEC plans. We can of course explain all of our choices but I would rather not do that for a while so that we don't prevent a conversation from developing.
cheers Jay
![](https://secure.gravatar.com/avatar/b5f1567b677d729395d8c1d64073d09f.jpg?s=120&d=mm&r=g)
I'm far from an expert in DNS or DNSSEC but I do believe that we can't let this get swept under the rug; I have a strong respect for the technical nous of many on NZNOG and with a strong operational context, NZNOG seems like an ideal place to discuss this. Most folks here know my background and interests. There's a few areas I have some thoughts on:
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.
Given the above feedback i'd love to know why a smaller keysize has been put up for .nz - Jay, this is one area an early comment on might be smart.
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.
'Standard Pre-Employment Checks' could mean essentially nothing at all. It could mean a Police Records Check and a Referees check. It could mean a lot more depending on whos definition of 'standard' you run with. Given the importance of the .nz zone in terms of NZ's critical Internet Infrastructure i'm surprised that someone like CCIP hasn't stepped in here to recommend (at the very least) a clearly articulated set of checks. In the Government space there's obviously a series of vetting grades which range from 'Police Check' through to official vetting levels. CCIP through their parent org (GCSB) should be at least consulted on something such as this? Can NZRS advice what benchmark they're using for personnel vetting?
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.
I like the idea of Trusted Community Representatives and would advocate such a system being implemented within the .nz space - if only to ensure complete transparency in terms of the InternetNZ involvement and the access that various folks within InternetNZ may (or may not) have to the back-end. Neutral or external eyes are important and in New Zealand we're fortunate enough to have plenty of folks with an appropriate level of industry trust.
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?
Again, if we knew what benchmarks were being used and had some details of the process being followed by InternetNZ, these questions wouldn't need to be asked.
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.
Does InternetNZ have a change management system? A document management system? Even something done manually (does't have to be in a dif'able repository) with appropriate processes and oversight, would be adequate in my opinion.
. No information around the security aspects of the co-location sites. Other DPS documents have outlined the security features used and who has access.
There's a process from my time in Mil/Gov that is called 'Certification and Accreditation' that covers the need for both systems and sites to be evaluated from a security perspective. Has InternetNZ performed anything similar? C&A was a term from dealing specifically with sensitive or classified data, but the approach is ideal for something such as this. CCIP could no doubt provide advice.
. 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?
C&A (or similar) would cover this.
. 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.
'as necessary' is too vague for something this important.
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.
Big kudos to Dean for putting himself out there on this. The issues he raises and the questions he asks are reasonable, IMHO. At the very least InternetNZ should be able to get a feel for the response out of this group and make adjustments to suit. But it seems to me that there's some key points that need to be addressed. Mark. (Speaking personally, etc.)
![](https://secure.gravatar.com/avatar/91d2b3948ed1461038cf9bbf79219b8b.jpg?s=120&d=mm&r=g)
On 8/6/11 10:15 AM, "Mark Foster"
'Standard Pre-Employment Checks' could mean essentially nothing at all. It could mean a Police Records Check and a Referees check. It could mean a lot more depending on whos definition of 'standard' you run with.
Given the importance of the .nz zone in terms of NZ's critical Internet Infrastructure i'm surprised that someone like CCIP hasn't stepped in here to recommend (at the very least) a clearly articulated set of checks.
In the Government space there's obviously a series of vetting grades which range from 'Police Check' through to official vetting levels. CCIP through their parent org (GCSB) should be at least consulted on something such as this?
Also, it doesn't actually say that they passed the checks. Which is not facetious. A check just identifies risk, and it's perfectly reasonable to accept a risk after due consideration. But as Dean says, in this case we are delegating trust to NZRS. Given that, I'm less interested in knowing who they have chosen, rather I'm interested in the process they used. By way of example: if the trusted people employed by NZRS were Dean and Andy then I'd be happy to trust them. The implication is that I should therefore trust NZRS. But, after a while both Dean and Andy move on to other jobs. If I only trust NZRS because I trust Dean and Andy then I should automatically revoke my trust in NZRS. By this model, I only trust NZRS once I, personally, have vetted their officers. And so for everyone else. Each of us doing background checks on the potential candidates. That's obviously nonsense: NZRS is the persistent entity that wants our trust, so it is up to NZRS to show why it should be trusted, and why it should continue to be trusted. Another example: a notorious confidence trickster was asked how he could take advantage of people who trusted him. He replied condescendingly that "because it only works if they *do* trust you). If someone wants to subvert NZRS, then they will be personable and engaging and oh so trustworthy and will have glowing references. Or, you could just suborn them by threatening their family. Which leads me to ask, is if possible for no one person to know the key, but rather to have just a portion of a key? Regardless, and in support of Dean's position I think, can we have the exact processes around the keeping of the keys set out on an open forum so we can evaluate them? -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 555 500 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.
![](https://secure.gravatar.com/avatar/4f215ac6755aff3820533ec4ffbe6aa8.jpg?s=120&d=mm&r=g)
On Wed, Jun 8, 2011 at 10:59 AM, Michael Newbery
Which leads me to ask, is if possible for no one person to know the key, but rather to have just a portion of a key?
That's exactly the process used for the Root signing process. There are seven crypto officers for each of the two signing locations. When the original signing processes occurred we all had to be present and we initialised portions of a key on smart cards. Each of us stores these in a tamper proof bag in an individual safe deposit box in the facility. When I travel to the ceremonies I take a physical key to that box and we have a very clear process to check the smart cards in and out. Three of the seven crypto officers must be present for the renewal to take place. We do this every three months at the East and West coast facilities There are backup procedures to cope with various contingencies - not enough crypto officers, lost keys and so on. The whole process is set out as a series of steps which we follow rigourously - you can see the audit trail for the ceremonies at http://data.iana.org/ksk-ceremony In particular, the initial ceremony I attended is documented at http://data.iana.org/ksk-ceremony/2/ceremony2-script-annotated.pdf Do we need a process that's as detailed and elaborate? Perhaps not but we do need a process we can trust. I'm going to make a commitment to the NZ Internet community that as a member of the DNCL Board I won't agree to a process that doesn't have the support of the community for the DNSSEC signing of .nz - exactly what that looks like needs to be discussed, negotiated and agreed. I'll echo the requests made by others on this list for a clear description of the processes. andy
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
On 8/06/2011, at 10:59 AM, Michael Newbery wrote:
Which leads me to ask, is if possible for no one person to know the key, but rather to have just a portion of a key?
Not if the controls are followed. In any system, ours as proposed for .nz, or the TCR system for the root, collusion between multiple bad actors can lead to controls being subverted and key material stolen.
Regardless, and in support of Dean's position I think, can we have the exact processes around the keeping of the keys set out on an open forum so we can evaluate them?
That's what publishing the DPS is intended to achieve. Is the level of detail in there on key management processes sufficient? I should, in tandem with Andy's commitment, firmly commit that we in NZRS will only proceed with DNSSEC plans that have community acceptance. In fact this is something we feel so strongly about that before we published our DNSSEC plans we proposed to our regulator (DNCL) that community acceptance of our plans be a formal metric in our SLA. Hence my desire to have this discussion in public and not private, so that people get a fair go at hearing the various concerns and explanations and can make informed assessments of our proposals. cheers Jay
-- Michael Newbery IP Architect TelstraClear Limited
TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 555 500 Enterprise & Government 0508 400 300
This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks. _______________________________________________ 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
![](https://secure.gravatar.com/avatar/91d2b3948ed1461038cf9bbf79219b8b.jpg?s=120&d=mm&r=g)
On 8/6/11 12:22 PM, "Jay Daley"
On 8/06/2011, at 10:59 AM, Michael Newbery wrote:
Which leads me to ask, is if possible for no one person to know the key, but rather to have just a portion of a key?
Not if the controls are followed.
In any system, ours as proposed for .nz, or the TCR system for the root, collusion between multiple bad actors can lead to controls being subverted and key material stolen.
And unless I'm missing something, all that takes for .nz is the collusion of two people: one SA and one SO. The root by contrast requires much greater collusion. The paragraph I have a little trouble with is: "A System Administrator is allowed to physically access the device containing the keys. A Security Officer is allowed to access the keystore holding the keys." Cast in the passive voice, this doesn't actually tell me who enforces this, nor in what manner.
That's what publishing the DPS is intended to achieve. Is the level of detail in there on key management processes sufficient?
Close, in fact maybe this discussion will establish that they are sufficient. -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 555 500 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.
![](https://secure.gravatar.com/avatar/b21b7c7d0abf3ca77426817e1d214cf5.jpg?s=120&d=mm&r=g)
On 06/08/2011 12:57 PM, Michael Newbery wrote:
On 8/6/11 12:22 PM, "Jay Daley"
wrote: On 8/06/2011, at 10:59 AM, Michael Newbery wrote:
Which leads me to ask, is if possible for no one person to know the key, but rather to have just a portion of a key?
Not if the controls are followed.
In any system, ours as proposed for .nz, or the TCR system for the root, collusion between multiple bad actors can lead to controls being subverted and key material stolen.
And unless I'm missing something, all that takes for .nz is the collusion of two people: one SA and one SO. The root by contrast requires much greater collusion.
The paragraph I have a little trouble with is: "A System Administrator is allowed to physically access the device containing the keys. A Security Officer is allowed to access the keystore holding the keys."
Cast in the passive voice, this doesn't actually tell me who enforces this, nor in what manner.
Let me clarify this a little bit more. A person wanting to access the keystore will require two credentials to do so. One credential to access the signing box, and a different credential to access the keystore. The way it's worded in the policy is only System Administrators hold a credential to access the signing box, and only Security Officers hold a credential to access the keystore. Never one person can fulfill both roles. So it's proposed as a four-eye principle (or split knowledge).
That's what publishing the DPS is intended to achieve. Is the level of detail in there on key management processes sufficient?
Close, in fact maybe this discussion will establish that they are sufficient.
Cheers, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/d982e71aaedffd3a6c40a6a7ca2aa87b.jpg?s=120&d=mm&r=g)
Jay Daley wrote:
[...] 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.
Any such problem seems very unlikely, unless you are planning several changes per week. - Donald Neal -- Donald Neal |"The aim of business is not to provide a | good service, but to provide the only High Performance Computing | service." - Reacher Gilt The University of Waikato |
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
On 8/06/2011 11:56 a.m., Donald Neal wrote:
Jay Daley wrote:
[...] 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.
Any such problem seems very unlikely, unless you are planning several changes per week.
I raised this point earlier and agree with Donald. We currently get NZRR updates all the time. I'm sure most people have those flagged to tuck away into a folder if they're not interested in it. -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 www.thinkdesignprint.co.nz
![](https://secure.gravatar.com/avatar/c2accc62fde48a7171651f4cdea19e4e.jpg?s=120&d=mm&r=g)
On 06/08/11 00:56, Donald Neal wrote:
Jay Daley wrote:
[...] 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.
Any such problem seems very unlikely, unless you are planning several changes per week.
Given the number of "NZRR Route Registry Update"s, it appears even several changes per week would be acceptable.
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
Thanks for this Jay. 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. On 8/06/11 11:40 AM, Jay Daley wrote:
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
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. 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?
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
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
On 9/06/2011 1:10 p.m., Jay Daley wrote:
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.
<big snip...>
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?
.nz - 1280 bit .au[1] - 2048 bit Which one is more secure? "When shopping on a web site you should consider looking for a .au site simply because the dns system is more secure. In New Zealand they only offer 1280 bit v's the 2048 bit that we offer our customers here in Australia... <Insert more FUD as desired>". Yes, I read Jay's explanation, but are we going to have to write... "In NZ we offer 1280/1 v's 2048/5, so in fact our is more secure...." If you look at my numbers above from a purely emotive point of view, with limited technical understanding then 2048/5 just looks bigger, and a bigger bank vault = more secure in most peoples eyes even if it's not. Trust is often as much about perception as reality. D [1] insert random country of your choice that I might be wanting to do business with.... .au is simply an example. -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 www.thinkdesignprint.co.nz
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
On 9/06/2011, at 1:49 PM, Don Gould wrote:
On 9/06/2011 1:10 p.m., Jay Daley wrote:
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.
<big snip...>
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?
.nz - 1280 bit .au[1] - 2048 bit
Which one is more secure?
2048, undoubtedly so, but the issue is whether 1280 is good enough and by what margin. Our view is that it is good enough and by such a wide margin that shifting up to 2048 just adds resource costs onto our customers unnecessarily. After all 4096 is even more secure, so why not use that?
"When shopping on a web site you should consider looking for a .au site simply because the dns system is more secure. In New Zealand they only offer 1280 bit v's the 2048 bit that we offer our customers here in Australia... <Insert more FUD as desired>".
Yes, I read Jay's explanation, but are we going to have to write...
"In NZ we offer 1280/1 v's 2048/5, so in fact our is more secure...."
If you look at my numbers above from a purely emotive point of view, with limited technical understanding then 2048/5 just looks bigger, and a bigger bank vault = more secure in most peoples eyes even if it's not.
Trust is often as much about perception as reality.
I agree, but in this case the perception issue is going to be between DNSSEC protected domains and domains not protected by DNSSEC, not key lengths. We know that from the precedent established with X.509 certs where people have no idea about cypher strength and key-length downgrades despite this being much more of a security threat than protection of the DNS data. cheers Jay
D
[1] insert random country of your choice that I might be wanting to do business with.... .au is simply an example.
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 www.thinkdesignprint.co.nz
_______________________________________________ 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
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
I noted the call to move to 2048... ...but I will comment on the 4096 question... On 9/06/2011 2:00 p.m., Jay Daley wrote:
After all 4096 is even more secure, so why not use that?
"We're not sure why New Zealand chooses quite such strong encryption on their DNS system, but it does slow your computer down, meaning you're likely to need a faster computer to get a great experience from their shopping sites... or you could use ours, which offer the same level of protection as used around the rest of the world." As with 1280, 4096 would be putting us out of step with the rest of the world.
Trust is often as much about perception as reality. I agree, but in this case the perception issue is going to be between DNSSEC protected domains and domains not protected by DNSSEC, not key lengths. I'm not sure I agree with that.
We know that from the precedent established with X.509 certs where people have no idea about cypher strength and key-length downgrades despite this being much more of a security threat than protection of the DNS data. Yes, I do agree that an SSL cert may as well be 8bit for all the average consumer cares, knows or understands. However, how do you spot what level the cert is in your browser?
If it's got a little padlock it's secure - right! With a url it's easy... www.shopping.co.NZ v's www.shopping.com.AU. Once the perception is out that there .nz is less secure than .WhatEver then it just becomes easy as to spot... "Don't shop in New Zealand". D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
![](https://secure.gravatar.com/avatar/34a7655fc8589ac784345a27d441918e.jpg?s=120&d=mm&r=g)
Hi Jay, On 2011-06-09 13:10 , Jay Daley wrote:
To recap and add some more detail, our explanation for choosing 1280 is: [....] 3. Recommendations by standards bodies in this area come into two categories[....] 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).
As an engineering observation, 2014 is _really_ close (approximately 24 months from deployment), and 2017 is still uncomfortably close. I understand that your usage method means that you might realistically believe that your safe usage time is longer than what you quoted (safer use case). But as a "worst case" engineering margin, "we'll be okay for at least a couple of years" is rather too close for comfort for me. (It looks very much like "we think that this is the minimum we can get away with".) One need only look at, eg, research into MD5 weaknesses over the last few years to see how rapidly "probably safe for now" can become "oh dear, we need something else" in the cryptographic world with a single breakthrough. Thus the typical cryptographic design allows quite a lot of engineering margin.
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.
My (admittedly high level) understanding is that the KSK (public key portion and signatures) would typically be seen/transferred by DNS clients (recursive caches) relatively infrequently. As the KSK is used solely for signing ZSKs. ZSK signatures would be expected to appear on the wire all the time, and the size of those is reasonably a packet size consideration. But the ZSK public key itself, and the KSK signatures are surely only on the wire rarely, and thus their impact on the packets should be relatively insignificant. Possibly I'm missing something here, but I had thought that DNSSEC was designed to avoid the "certificate chain bulk" of, eg, SSL/TLS/HTTPS for this reason. FWIW, it's been a long time since 2048-bit crypto keys presented a significant workload to modern CPUs when verifying signatures. And I'd expect KSK signature verification to be sufficiently infrequent not to dominate CPU usage; ZSK signature verifications would be expected to happen "all the time", and thus a CPU concern. I could, eg, see a 2048-bit KSK (rolled, eg, yearly) and a 1024-bit ZSK (rolled fairly frequently) as a reasonable engineering trade off. But I'm struggling to see a 1280-bit KSK as a reasonable choice in 2011. Given that it appears someone has done some careful maths to determine that 1280-bits is the largest they're willing to recommend, perhaps you could explain how that translates into packet size boundaries that you're concerned about? (Eg, 512-byte UDP minimums? 1500-byte (ethernet) common packets?) And how frequently those packets are expected to be transferred (eg, every response, once per TTL, etc). Also it may help to speak to why, eg, 1536-bit wasn't being suggested if you wanted "smaller than 2048-bit" size.
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.
Surely that's at least as strong an argument for taking the safe engineering approach, to avoid everyone else getting hooked on a "hopefully safe for 2-5 years, all going well" approach and immediately having to re-engineer things following a discovery that makes key cracking 10% easier. Ewen PS: I must say, for the record, that I find it extremely refreshing that their are NZRS staff who are both willing to have this discussion in public, and able to discuss the technical issues in detail.
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Hi Ewen On 9/06/2011, at 1:58 PM, Ewen McNeill wrote:
As an engineering observation, 2014 is _really_ close (approximately 24 months from deployment), and 2017 is still uncomfortably close. I understand that your usage method means that you might realistically believe that your safe usage time is longer than what you quoted (safer use case). But as a "worst case" engineering margin, "we'll be okay for at least a couple of years" is rather too close for comfort for me. (It looks very much like "we think that this is the minimum we can get away with".)
Not in the slightest. Our job is the management of risk to operate what it clearly critical infrastructure. We manage risk very carefully, but at the same time we don't over-engineer as it is clear that that approach introduces as many problems as it solves.
One need only look at, eg, research into MD5 weaknesses over the last few years to see how rapidly "probably safe for now" can become "oh dear, we need something else" in the cryptographic world with a single breakthrough. Thus the typical cryptographic design allows quite a lot of engineering margin.
Sorry, I was simplifying this a bit much. The timescales are given on a 2004 prediction that it would cost 400m dollardays to break a 1024 bit key and then extrapolating up using Moore's law as to what size key could be broken using 40m dollardays and by when. It's all theory but the best we have so far. In reality even a 1024 bit key has not yet been broken and each added bit doubles the time it takes to break a key. However, thank you, that's a very useful opinion.
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.
My (admittedly high level) understanding is that the KSK (public key portion and signatures) would typically be seen/transferred by DNS clients (recursive caches) relatively infrequently. As the KSK is used solely for signing ZSKs. ZSK signatures would be expected to appear on the wire all the time, and the size of those is reasonably a packet size consideration. But the ZSK public key itself, and the KSK signatures are surely only on the wire rarely, and thus their impact on the packets should be relatively insignificant.
Possibly I'm missing something here, but I had thought that DNSSEC was designed to avoid the "certificate chain bulk" of, eg, SSL/TLS/HTTPS for this reason.
FWIW, it's been a long time since 2048-bit crypto keys presented a significant workload to modern CPUs when verifying signatures. And I'd expect KSK signature verification to be sufficiently infrequent not to dominate CPU usage; ZSK signature verifications would be expected to happen "all the time", and thus a CPU concern.
I could, eg, see a 2048-bit KSK (rolled, eg, yearly) and a 1024-bit ZSK (rolled fairly frequently) as a reasonable engineering trade off. But I'm struggling to see a 1280-bit KSK as a reasonable choice in 2011.
Given that it appears someone has done some careful maths to determine that 1280-bits is the largest they're willing to recommend, perhaps you could explain how that translates into packet size boundaries that you're concerned about? (Eg, 512-byte UDP minimums? 1500-byte (ethernet) common packets?) And how frequently those packets are expected to be transferred (eg, every response, once per TTL, etc). Also it may help to speak to why, eg, 1536-bit wasn't being suggested if you wanted "smaller than 2048-bit" size.
AFAIK we do have that info in the office, but I'll need to check.
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.
Surely that's at least as strong an argument for taking the safe engineering approach, to avoid everyone else getting hooked on a "hopefully safe for 2-5 years, all going well" approach and immediately having to re-engineer things following a discovery that makes key cracking 10% easier.
I note that neither you, nor I, nor Dean has revoked our 1024 bit openPGP keys!
Ewen
PS: I must say, for the record, that I find it extremely refreshing that their are NZRS staff who are both willing to have this discussion in public, and able to discuss the technical issues in detail.
You're welcome! cheers Jay
_______________________________________________ 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
![](https://secure.gravatar.com/avatar/34a7655fc8589ac784345a27d441918e.jpg?s=120&d=mm&r=g)
Hi Jay, On 2011-06-09 14:44 , Jay Daley wrote:
I note that neither you, nor I, nor Dean has revoked our 1024 bit openPGP keys!
Not yet. But at least in my case, I created larger keys (4096-bit) 18 months ago and have collecting signatures on them, and been using those in preference to the 1024-bit OpenPGP keys where possible since then. So that I'd be in a position to abandon (revoke) the 1024-bit key at "any moment". Ie, my transition plan away from those 1024-bit keys is already well under way; it's just not complete yet. One might also observe that the risk profile of "a ccTLD" and the risk profile of "a small company"/"an individual" are somewhat different; to the extent that one might expect to spend (money, CPU time, bandwidth, etc) orders of magnitude more on security for the former over the latter. It would, IMHO, be unfortunate to get through the deployment of DNSSEC for .nz and have to _immediately_ launch into the transition plan for a stronger version because the first deployment was no longer (perceived as) suitable. [reordered]
[...] but at the same time we don't over-engineer as it is clear that that approach introduces as many problems as it solves.
In civil engineering one of the rules of thumb is that things be designed to handle _at_minimum_ three times the maximum expected load. That's clearly "over engineering". But it's accepted Best Practice, because it provides a margin for error in case some of the estimates turn out not to be true (or the future presents something that was not anticipated -- people marching in step on the London Millennium bridge for instance). If you were, eg, suggesting the KSK be 4096-bit keys, rolled every 2 months, or something else that was orders of magnitude more "paranoid" than common practice, then it would be right to be concerned about "over engineering". Where you want to engineer something with much less margin for error than common practice, it's reasonable to expect that others will want to look closely at the justifications for "under specifying" too. And in particular whether there is still adequate margin for error, throughout the expected deployment lifetime. I, like Dean I believe, remain to be convinced on this point. Ewen
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Ewen On 9/06/2011, at 3:06 PM, Ewen McNeill wrote:
Hi Jay,
On 2011-06-09 14:44 , Jay Daley wrote:
I note that neither you, nor I, nor Dean has revoked our 1024 bit openPGP keys!
Not yet. But at least in my case, I created larger keys (4096-bit) 18 months ago and have collecting signatures on them, and been using those in preference to the 1024-bit OpenPGP keys where possible since then. So that I'd be in a position to abandon (revoke) the 1024-bit key at "any moment". Ie, my transition plan away from those 1024-bit keys is already well under way; it's just not complete yet.
Quite right - apologies if my quip offended you.
One might also observe that the risk profile of "a ccTLD" and the risk profile of "a small company"/"an individual" are somewhat different; to the extent that one might expect to spend (money, CPU time, bandwidth, etc) orders of magnitude more on security for the former over the latter.
It would, IMHO, be unfortunate to get through the deployment of DNSSEC for .nz and have to _immediately_ launch into the transition plan for a stronger version because the first deployment was no longer (perceived as) suitable.
The only transition would be to rollover to a key of a bigger size having amended the DPS to state that and let people know.
[reordered]
[...] but at the same time we don't over-engineer as it is clear that that approach introduces as many problems as it solves.
In civil engineering one of the rules of thumb is that things be designed to handle _at_minimum_ three times the maximum expected load. That's clearly "over engineering". But it's accepted Best Practice, because it provides a margin for error in case some of the estimates turn out not to be true (or the future presents something that was not anticipated -- people marching in step on the London Millennium bridge for instance).
If you were, eg, suggesting the KSK be 4096-bit keys, rolled every 2 months, or something else that was orders of magnitude more "paranoid" than common practice, then it would be right to be concerned about "over engineering". Where you want to engineer something with much less margin for error than common practice, it's reasonable to expect that others will want to look closely at the justifications for "under specifying" too. And in particular whether there is still adequate margin for error, throughout the expected deployment lifetime. I, like Dean I believe, remain to be convinced on this point.
Taking your engineering argument as a way forward - the largest RSA key to have been broken so far (that is publicly known) is 1023 bits and even that was a very special key. A 1280 bit key is 2^257 or 231,584,178,474,632,390,847,141,970,017,375,815,706,539,969,331, 281,128,078,915,168,015,826,259,279,872 times as strong as that. So let's say someone announced today that they could factor a 1024 bit key in just 1 second, it would take them 3,671,743,063,080,802,746,815,416,825,491,118,336,290,905,145,409,708,398,004,109,081,935,347 years to factor a 1280 bit key. We are already "over-engineering" but not "over-over-engineering". cheers Jay
Ewen
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
![](https://secure.gravatar.com/avatar/34a7655fc8589ac784345a27d441918e.jpg?s=120&d=mm&r=g)
On 2011-06-09 15:25 , Jay Daley wrote:
Taking your engineering argument as a way forward - the largest RSA key to have been broken so far (that is publicly known) is 1023 bits and even that was a very special key. A 1280 bit key is 2^257 [stronger, so we have years]
You appear to be under the impression that advances in cryptographic key breaking only ever proceed at a linear pace, exactly matching Moore's Law improvements in equipment. This is not the case. Better cryptographic attacks are discovered from time to time that make it not just linearly easier to break a given key/cipher, but advance at the equivalent of many times "Moore's Law" gains at the stroke of a pen. This happened to MD5 about 5 years ago, hence my statement that it went at a moment from "a little weak, but okay for now" to "we have to change algorithms" in the release of a single research paper. (See, eg, http://en.wikipedia.org/wiki/MD5#Security for a summary of the events.) For this reason, in cryptographic engineering, one allows not just a linear amount of margin for safety ("most we can break now is 1023-bit, Moores law doubles every 18 months, we need 3 years, so 1025-bits will be enough") but quite a bit more, in order to deal with the risk that 10%, 20%, or more, of the perceived key strength can be rendered irrelevant by a single research paper. Ewen
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Hi Ewen On 9/06/2011, at 3:36 PM, Ewen McNeill wrote:
On 2011-06-09 15:25 , Jay Daley wrote:
Taking your engineering argument as a way forward - the largest RSA key to have been broken so far (that is publicly known) is 1023 bits and even that was a very special key. A 1280 bit key is 2^257 [stronger, so we have years]
You appear to be under the impression that advances in cryptographic key breaking only ever proceed at a linear pace, exactly matching Moore's Law improvements in equipment.
This is not the case.
That wasn't my intention. I'm aware of the crypto advances you've detailed below, but what I was hoping to illustrate is just how large the margin of improvement needs to be for a 1280 bit key to be regarded as unsafe, even taking into account the possibility of clever advances jumping forward the rate by several orders of magnitude. cheers Jay
Better cryptographic attacks are discovered from time to time that make it not just linearly easier to break a given key/cipher, but advance at the equivalent of many times "Moore's Law" gains at the stroke of a pen. This happened to MD5 about 5 years ago, hence my statement that it went at a moment from "a little weak, but okay for now" to "we have to change algorithms" in the release of a single research paper. (See, eg, http://en.wikipedia.org/wiki/MD5#Security for a summary of the events.)
For this reason, in cryptographic engineering, one allows not just a linear amount of margin for safety ("most we can break now is 1023-bit, Moores law doubles every 18 months, we need 3 years, so 1025-bits will be enough") but quite a bit more, in order to deal with the risk that 10%, 20%, or more, of the perceived key strength can be rendered irrelevant by a single research paper.
Ewen
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
![](https://secure.gravatar.com/avatar/155f1500e005d1fbbaf246ed5bce9277.jpg?s=120&d=mm&r=g)
Going to jump into the middle of this, I have as much cryptographic knowledge as a French door but this statement does sound a bit like "The unsinkable ship". Rather than focus on the technical aspects of it (2048bit will always be safer than 1280bit) I would like to ask why. What exactly is the extra hassle/cost in running with a 2048bit key? Is it really big enough to justify going with a weaker key? I understand that the key lifespan is planned to be shorter but it does sound like an unnecessary risk. Cheers -- Tristram Cheer Network Architect Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 Fax. | tristram.cheer(a)ubergroup.co.nz | www.ubergroup.co.nz PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Jay Daley Sent: Thursday, 9 June 2011 3:26 p.m. To: Ewen McNeill Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
[reordered]
[...] but at the same time we don't over-engineer as it is clear that that approach introduces as many problems as it solves.
In civil engineering one of the rules of thumb is that things be designed to handle _at_minimum_ three times the maximum expected load. That's clearly "over engineering". But it's accepted Best Practice, because it provides a margin for error in case some of the estimates turn out not to be true (or the future presents something that was not anticipated -- people marching in step on the London Millennium bridge for instance).
If you were, eg, suggesting the KSK be 4096-bit keys, rolled every 2 months, or something else that was orders of magnitude more "paranoid" than common practice, then it would be right to be concerned about "over engineering". Where you want to engineer something with much less margin for error than common practice, it's reasonable to expect that others will want to look closely at the justifications for "under specifying" too. And in particular whether there is still adequate margin for error, throughout the expected deployment lifetime. I, like Dean I believe, remain to be convinced on this point.
Taking your engineering argument as a way forward - the largest RSA key to have been broken so far (that is publicly known) is 1023 bits and even that was a very special key. A 1280 bit key is 2^257 or 231,584,178,474,632,390,847,141,970,017,375,815,706,539,969,331, 281,128,078,915,168,015,826,259,279,872 times as strong as that. So let's say someone announced today that they could factor a 1024 bit key in just 1 second, it would take them 3,671,743,063,080,802,746,815,416,825,491,118,336,290,905,145,409,708,398,004,109,081,935,347 years to factor a 1280 bit key. We are already "over-engineering" but not "over-over-engineering". cheers Jay
Ewen
-- 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
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Hi Tristram On 9/06/2011, at 3:40 PM, Tristram Cheer wrote:
Going to jump into the middle of this, I have as much cryptographic knowledge as a French door but this statement does sound a bit like "The unsinkable ship".
Thanks for taking the time to jump in!
Rather than focus on the technical aspects of it (2048bit will always be safer than 1280bit) I would like to ask why. What exactly is the extra hassle/cost in running with a 2048bit key? Is it really big enough to justify going with a weaker key? I understand that the key lifespan is planned to be shorter but it does sound like an unnecessary risk.
The danger with that is that we get into the trap of infinite regression. We know that 1280 is weaker than 2048 is weaker than 4096. So when we start to use comparators we end up pushing upwards as high as possible. The question should be "Is 1280 strong enough and with a sufficient margin of error in the strength?". Our answer would be yes and yes with an enormous margin of error. cheers Jay
Cheers
--
Tristram Cheer Network Architect
Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 Fax. | tristram.cheer(a)ubergroup.co.nz | www.ubergroup.co.nz
PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd
-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Jay Daley Sent: Thursday, 9 June 2011 3:26 p.m. To: Ewen McNeill Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
[reordered]
[...] but at the same time we don't over-engineer as it is clear that that approach introduces as many problems as it solves.
In civil engineering one of the rules of thumb is that things be designed to handle _at_minimum_ three times the maximum expected load. That's clearly "over engineering". But it's accepted Best Practice, because it provides a margin for error in case some of the estimates turn out not to be true (or the future presents something that was not anticipated -- people marching in step on the London Millennium bridge for instance).
If you were, eg, suggesting the KSK be 4096-bit keys, rolled every 2 months, or something else that was orders of magnitude more "paranoid" than common practice, then it would be right to be concerned about "over engineering". Where you want to engineer something with much less margin for error than common practice, it's reasonable to expect that others will want to look closely at the justifications for "under specifying" too. And in particular whether there is still adequate margin for error, throughout the expected deployment lifetime. I, like Dean I believe, remain to be convinced on this point.
Taking your engineering argument as a way forward - the largest RSA key to have been broken so far (that is publicly known) is 1023 bits and even that was a very special key. A 1280 bit key is 2^257 or 231,584,178,474,632,390,847,141,970,017,375,815,706,539,969,331, 281,128,078,915,168,015,826,259,279,872 times as strong as that. So let's say someone announced today that they could factor a 1024 bit key in just 1 second, it would take them 3,671,743,063,080,802,746,815,416,825,491,118,336,290,905,145,409,708,398,004,109,081,935,347 years to factor a 1280 bit key.
We are already "over-engineering" but not "over-over-engineering".
cheers Jay
Ewen
-- 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 _______________________________________________ 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
![](https://secure.gravatar.com/avatar/b21b7c7d0abf3ca77426817e1d214cf5.jpg?s=120&d=mm&r=g)
On 06/09/2011 01:58 PM, Ewen McNeill wrote:
Hi Jay,
Hi Ewen,
On 2011-06-09 13:10 , Jay Daley wrote:
To recap and add some more detail, our explanation for choosing 1280 is: [....] 3. Recommendations by standards bodies in this area come into two categories[....] 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).
As an engineering observation, 2014 is _really_ close (approximately 24 months from deployment), and 2017 is still uncomfortably close. I understand that your usage method means that you might realistically believe that your safe usage time is longer than what you quoted (safer use case). But as a "worst case" engineering margin, "we'll be okay for at least a couple of years" is rather too close for comfort for me. (It looks very much like "we think that this is the minimum we can get away with".)
The intention of the policy (including the key sizes) is to be a live document. If at some point there is concern from NZRS or the community about the KSK length, the system is prepared to change the size of the keys fairly quickly. So we can start with a 1280-bit KSK and later increase the size of the key.
One need only look at, eg, research into MD5 weaknesses over the last few years to see how rapidly "probably safe for now" can become "oh dear, we need something else" in the cryptographic world with a single breakthrough. Thus the typical cryptographic design allows quite a lot of engineering margin.
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.
My (admittedly high level) understanding is that the KSK (public key portion and signatures) would typically be seen/transferred by DNS clients (recursive caches) relatively infrequently. As the KSK is used solely for signing ZSKs. ZSK signatures would be expected to appear on the wire all the time, and the size of those is reasonably a packet size consideration. But the ZSK public key itself, and the KSK signatures are surely only on the wire rarely, and thus their impact on the packets should be relatively insignificant.
The KSK is used to sign the key set (KSK + ZSK). The ZSK is used to sign the rest of the data in the zone. The query type for the key set is DNSKEY, which will be queried by a validating resolver once each TTL. Signatures travel together with the data, so in the case of a DNSKEY, the corresponding signatures go together. During normal operation, the key set will contain two keys (one KSK and one ZSK) plus one signature. During a ZSK rollover, an extra key will be present. During a KSK rollover, an extra key and extra signature. If we consider an emergency KSK and ZSK, during normal operation we will end up with 4 keys in the keyset.
Possibly I'm missing something here, but I had thought that DNSSEC was designed to avoid the "certificate chain bulk" of, eg, SSL/TLS/HTTPS for this reason.
FWIW, it's been a long time since 2048-bit crypto keys presented a significant workload to modern CPUs when verifying signatures. And I'd expect KSK signature verification to be sufficiently infrequent not to dominate CPU usage; ZSK signature verifications would be expected to happen "all the time", and thus a CPU concern.
I could, eg, see a 2048-bit KSK (rolled, eg, yearly) and a 1024-bit ZSK (rolled fairly frequently) as a reasonable engineering trade off. But I'm struggling to see a 1280-bit KSK as a reasonable choice in 2011.
Given that it appears someone has done some careful maths to determine that 1280-bits is the largest they're willing to recommend, perhaps you could explain how that translates into packet size boundaries that you're concerned about? (Eg, 512-byte UDP minimums? 1500-byte (ethernet) common packets?) And how frequently those packets are expected to be transferred (eg, every response, once per TTL, etc). Also it may help to speak to why, eg, 1536-bit wasn't being suggested if you wanted "smaller than 2048-bit" size.
We investigated different KSK sizes and their effect in response sizes for a DNSKEY query. The 512-byte limit was a concern before initial DNSSEC deployment, but the system seems to be coping well. The main concern is about clients supporting EDNS but being unable to receive fragmented packets. So we aimed to have a DNSKEY response below the 1420-bytes (Ethernet MTU - headers). The following table represents the size in bytes of a key of certain size as represented in the DNS packet: keysz rdlen 1024 136 1280 168 1408 184 1536 200 1664 216 1792 232 1920 248 2048 264 The following table represents the size in bytes of a RRSIG record created using a key of certain size: keysz rdlen 1280 187 1408 203 1536 219 1664 235 1792 251 1920 267 2048 278 With this data, you can play around different scenarios. Please note each DNS response has an overhead of aprox 100 bytes. That number is based on experimentation and was obtained as the difference between the response size and the sum of sizes of the keys/signatures in the response. Assuming a 1024-bit ZSK, we have: KSKSz # KSK #ZSK #RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 1 1 1 168 136 187 591 1408 1 1 1 184 136 203 623 1536 1 1 1 200 136 219 655 1664 1 1 1 216 136 235 687 1792 1 1 1 232 136 251 719 1920 1 1 1 248 136 267 751 2048 1 1 1 264 136 278 778 So far so good. During a ZSK rollover we get an additional ZSK KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 1 2 1 168 272 187 727 1408 1 2 1 184 272 203 759 1536 1 2 1 200 272 219 791 1664 1 2 1 216 272 235 823 1792 1 2 1 232 272 251 855 1920 1 2 1 248 272 267 887 2048 1 2 1 264 272 278 914 During a KSK rollover we have an additional KSK and RRSIG KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 2 1 2 336 136 374 946 1408 2 1 2 368 136 406 1010 1536 2 1 2 400 136 438 1074 1664 2 1 2 432 136 470 1138 1792 2 1 2 464 136 502 1202 1920 2 1 2 496 136 534 1266 2048 2 1 2 528 136 556 1320 The 2048-bit key is very close to the limit, but still good. What if the KSK and ZSK rollover happen at the same time. KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 2 2 2 336 272 374 1082 1408 2 2 2 368 272 406 1146 1536 2 2 2 400 272 438 1210 1664 2 2 2 432 272 470 1274 1792 2 2 2 464 272 502 1338 1920 2 2 2 496 272 534 1402 2048 2 2 2 528 272 556 1456 That doesn't look that bad. If we use an emergency KSK during a rollover, things get bigger KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 3 2 2 504 272 374 1250 1408 3 2 2 552 272 406 1330 1536 3 2 2 600 272 438 1410 1664 3 2 2 648 272 470 1490 1792 3 2 2 696 272 502 1570 1920 3 2 2 744 272 534 1650 2048 3 2 2 792 272 556 1720 The worst case: emergency KSK and ZSK during a KSK and ZSK rollover KSKsz # KSK # ZSK # RRSIG KSK_sz ZSK_sz RRSIG_sz Total 1280 3 3 2 504 408 374 1386 1408 3 3 2 552 408 406 1466 1536 3 3 2 600 408 438 1546 1664 3 3 2 648 408 470 1626 1792 3 3 2 696 408 502 1706 1920 3 3 2 744 408 534 1786 2048 3 3 2 792 408 556 1856 For this long list of tables and numbers, you can see the 1280-bit KSK is a good trade-off between key strength and flexibility to operate rollovers in a way that ensures the chain of trust is not broken.
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.
Surely that's at least as strong an argument for taking the safe engineering approach, to avoid everyone else getting hooked on a "hopefully safe for 2-5 years, all going well" approach and immediately having to re-engineer things following a discovery that makes key cracking 10% easier.
Ewen
PS: I must say, for the record, that I find it extremely refreshing that their are NZRS staff who are both willing to have this discussion in public, and able to discuss the technical issues in detail. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Cheers, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
![](https://secure.gravatar.com/avatar/34a7655fc8589ac784345a27d441918e.jpg?s=120&d=mm&r=g)
Hi Sebastian, On 2011-06-09 15:09 , Sebastian Castro wrote:
For this long list of tables and numbers, you can see the 1280-bit KSK is a good trade-off between key strength and flexibility to operate rollovers in a way that ensures the chain of trust is not broken.
Okay, I now understand how 1280 was chosen (worst case situation still fit into common Ethernet packet without fragmentation, as UDP), and why 1536 wasn't suitable in this worst case situation. Thank you for all the detailed tables. However I'll note that you appear to be solving a problem that (a) few others are solving, and (b) will rapidly become irrelevant. The supposed "can get 1500-byte UDP, but not larger UDP, won't retry properly with TCP" clients will indeed be able to follow the .nz chain of trust in this 1280 situation. But will fail to follow the chain of trust for many other (already deployed) TLDs. So they'll still have to fix their firewall rules/other equipment/whatever to continue to have good connectivity to the modern Internet. (It also seems likely to me that their first response to such broken equipment will be to turn off DNSSEC verification, at which point they won't even be seeing your "optimised to fit" DNSKEY responses, just the smaller ZSK signatures on other RRs they request.) If anything, to echo Jay, this seems like "over engineering" to solve a perceived problem that I'm not really convinced will exist in real life for more than a trivial amount of time. If it turns out that there is a genuine need at the initial deployment to allow more time for people to deal with the packet fragmentation/no-TCP issue, I'd probably live with "1280-bit ZSK in first year, raised to 1536-bit/2048-bit after 12 months" as a policy. But it's not clear to me that even that is needed. Ewen
![](https://secure.gravatar.com/avatar/b21b7c7d0abf3ca77426817e1d214cf5.jpg?s=120&d=mm&r=g)
On 06/09/2011 03:37 PM, Ewen McNeill wrote:
Hi Sebastian,
Hi Ewen,
On 2011-06-09 15:09 , Sebastian Castro wrote:
For this long list of tables and numbers, you can see the 1280-bit KSK is a good trade-off between key strength and flexibility to operate rollovers in a way that ensures the chain of trust is not broken.
Okay, I now understand how 1280 was chosen (worst case situation still fit into common Ethernet packet without fragmentation, as UDP), and why 1536 wasn't suitable in this worst case situation. Thank you for all the detailed tables.
However I'll note that you appear to be solving a problem that (a) few others are solving, and (b) will rapidly become irrelevant. The supposed "can get 1500-byte UDP, but not larger UDP, won't retry properly with TCP" clients will indeed be able to follow the .nz chain of trust in this 1280 situation. But will fail to follow the chain of trust for many other (already deployed) TLDs. So they'll still have to fix their firewall rules/other equipment/whatever to continue to have good connectivity to the modern Internet. (It also seems likely to me that their first response to such broken equipment will be to turn off DNSSEC verification, at which point they won't even be seeing your "optimised to fit" DNSKEY responses, just the smaller ZSK signatures on other RRs they request.)
I agree with point a), just a few are trying to solve the problem. This could be explained by who will be affected: a DNS operator is not likely to see the retries/dropped fragments from clients behind poorly-implemented firewalls, thus going unnoticed. In order to have a clear picture, more monitoring like the one done by Netalyzr is needed (http://conferences.npl.co.uk/satin/papers/satin2011-Weaver.pdf) About point b), a validating caching resolver is likely to stop DNSSEC validation if it causes problems (the path of least resistance). We don't want that. As you said, those clients will be able to continue resolving .nz domain names but they might fail with other TLDs, so we are not making the problem worst.
If anything, to echo Jay, this seems like "over engineering" to solve a perceived problem that I'm not really convinced will exist in real life for more than a trivial amount of time. If it turns out that there is a genuine need at the initial deployment to allow more time for people to deal with the packet fragmentation/no-TCP issue, I'd probably live with "1280-bit ZSK in first year, raised to 1536-bit/2048-bit after 12 months" as a policy. But it's not clear to me that even that is needed.
Cheers,
Ewen _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Having gone through significant discussion on the key length issue we are happy to acknowledge that the consensus on NZNOG is for us to increase our KSK size to 2048 bits for the following reason: - The community view is that 2048 bits is an appropriate key length based on the common practice in other registries and that view accepts that the increased resource implications of this key size are not significant enough to consider a shorter key size. Before we commit to that we would like to hear if there is any feedback from the NZISIG folks as they may usefully contribute to the debate. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
For those of you not on the NZISIG list, the following messages were posted there by Peter Guttmann on the subject of key sizes, which he has agreed I can repost to this list:
For the key size, see e.g. "The Curse of Cryptographic Numerology", http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5772965&tag=1 (you may need to be an IEEE member to get access to this, unfortunately).
OTOH if it's only for KSKs and not any other, frequently-used keys then it's not so bad, just use 1024 or 1280 bits for other keys. You're also fighting against organisations who've chosen their key sizes based on numerology rather than any real risk assessment, so you may have to bite the bullet even though it doesn't make any sense to use a longer key, and (as the Numerology article points out), is in fact a net detriment to security.
and
During DNSSEC's lifetime, there will inevitably be security breaches and compromises. The one thing that will never happen is that an attacker will factor the RSA key ("break" it), no matter what key size is used. Therefore any effort spent in debating key sizes is totally wasted, and should be expended on examining real weak points that attackers will actually exploit, and how to mitigate against attacks at those points.
The only reason for choosing a key size of 2048 bits rather than 1280 is through a conscious choice to make the same fashion statement that other countries are making. Since this is purely a fashion statement, it should be documented as such, i.e. "We use a key size of 2048 bits not because it provides any extra security but because other countries use it, and if we didn't then the vast majority of users who don't understand cryptography might incorrectly perceive us as being less secure. This key size has a negative impact due to extra processing overhead and message sizes, but this is deemed justifiable because <something about the cost of bad publicity being even worse>".
FWIW, I'd support staying with 1280 bits, if only so you/we (NZ) can point out how pointless other countries' using 2048 bits is. Then in ten years time we can all do a collective "I todja so!" when nothing happens.
This may be politically unacceptable though.
In the event that this changes anyone's views then please let me know before we settle on switching to 2048 bits. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
On 9/06/11 6:38 PM, Jay Daley wrote:
For those of you not on the NZISIG list, the following messages were posted there by Peter Guttmann on the subject of key sizes, which he has agreed I can repost to this list:
Ooooooh, I'll see your Guttmann and raise you a Guttmann (Hi Peter).
Peter's right of course, but he's also fighting an up hill battle here. And it's not the first time. I'll give you an example: Among the things that Peter is well known for, one of them is the "Guttmann Method" for wiping hard drives. You've all heard about it. Wiping a drive by overwriting it 35 times with differing patterns etc. Many of you may have used it. Many may have recommended it as being the one true way to wipe disks. It's become a cult following in IT circles, right the way into government even. But how many of you have read the Epilogue to the paper? "In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes." Sound familiar? And no one takes notice of it. People still swear by the 35 pass method and say that it's the safest. I've even had people refuse to accept disks as wiped if you use anything BUT the Guttmann Method. They are all wrong, but you just can't beat public perception [1]. I believe that Peter may very well be right about 1280 bits being enough, but are you really going to be able to convince everyone else to trust that? If people look at .com and it uses 2048 and .nz and they use 1280 bit, are they really going to do all the investigation we just have in order to assess the true security? They certainly don't do the research when they wipe harddrives. My final word on this is "1280 may well be enough from a security point of view, but there will be latent trust issues within the .nz target market if a key less then 2048 is chosen while other domains have adopted 2048". NZRS and the DNCL may want to consider this Regards, Dean [1] Unless you have an episode on mythbusters, then people never shut up about it being "BUSTED" =)
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
Hi Dean On 9/06/2011, at 10:07 PM, Dean Pemberton wrote: [snipped]
They are all wrong, but you just can't beat public perception [1].
I believe that Peter may very well be right about 1280 bits being enough, but are you really going to be able to convince everyone else to trust that?
So let me get this right - you do now agree that 1280 bits is sufficient but now claim that others might not believe that and so we need to change? I think that's called playing both sides of the fence. If you believe that key size is sufficient then you need to stand by that having started this thread in the first place.
If people look at .com and it uses 2048 and .nz and they use 1280 bit, are they really going to do all the investigation we just have in order to assess the true security?
I am pretty sure that as a statistical average, nobody at all is going to look at the KSK size when choosing a TLD.
They certainly don't do the research when they wipe harddrives.
My final word on this is "1280 may well be enough from a security point of view, but there will be latent trust issues within the .nz target market if a key less then 2048 is chosen while other domains have adopted 2048". NZRS and the DNCL may want to consider this
I am concerned that you will continue to claim "trust issues" unless you get your way fully on each item and the major "trust issues" we will then face are your claims of "trust issues" rather than any weaknesses in our processes. Can you assure me that will not be the case? cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
On 9/06/11 11:08 PM, Jay Daley wrote:
My final word on this is "1280 may well be enough from a security point of view, but there will be latent trust issues within the .nz target market if a key less then 2048 is chosen while other domains have adopted 2048". NZRS and the DNCL may want to consider this I am concerned that you will continue to claim "trust issues" unless you get your way fully on each item and the major "trust issues" we will then face are your claims of "trust issues" rather than any weaknesses in our processes. Can you assure me that will not be the case?
*sigh* There have been some well presented arguments for both 1280 and 2048 bit keys today. My initial query was to why 1280 keys had been chosen over 2048 bit keys, and that this seemed to be a departure from accepted practice. Both Sebastian and yourself have provided an enlightening discussion of the thought process behind this. You've even pulled in the BigGuns(tm). 1280 bit keys ARE less secure than 2048 bit keys, and as you point out, both of these are less secure than 4096 bit keys. So I believe that there are two issues here... 1) Are 1280 bit keys secure ENOUGH for a 1Y rolled KSK? 2) Is having a bit length smaller than the majority of other DNSSEC TLDs going to be a problem for people trusting .nz My answer to 1 is "I can't be sure, opinions vary, but NZRS has consulted experts in this field and they seem to suggest that it a viable option at present." My answer to 2 is "I believe that people will view the .nz DNSSEC implmentation as less secure if it has a smaller bit-length KSK. Regardless of whether they are right or wrong, that will be the public perception." What I do know for sure is, if you implement 2048 bit keys as you suggested in an earlier email, both of these questions are moot. Dean
![](https://secure.gravatar.com/avatar/7ae5fb6e0b5212fa4afaadbe221e3540.jpg?s=120&d=mm&r=g)
On Thu, Jun 09, 2011 at 11:38:47PM +1200, Dean Pemberton wrote:
There have been some well presented arguments for both 1280 and 2048 bit keys today. My initial query was to why 1280 keys had been chosen over 2048 bit keys, and that this seemed to be a departure from accepted practice. Both Sebastian and yourself have provided an enlightening discussion of the thought process behind this. You've even pulled in the BigGuns(tm).
accepted practice is driven by vendor defaults and recomendations, not always grounded in good practice. e.g. accepted != good.
1280 bit keys ARE less secure than 2048 bit keys, and as you point out, both of these are less secure than 4096 bit keys.
what do you mean by "secure"? harder to break, with all other factors being equal? perhaps true. -BUT- there is such a thing as "overkill" ... do you really need a 8192bit key for a DHCP lease lasting 15minutes? I am not persuaded that the information moved in that 15min interval needs a 20year protection window. What was missing in the presumptive key selection was the temporal lifespan of the key. As mentioned earlier, a 1280/1 key might be stronger than a 2048/5 key.
So I believe that there are two issues here...
1) Are 1280 bit keys secure ENOUGH for a 1Y rolled KSK? 2) Is having a bit length smaller than the majority of other DNSSEC TLDs going to be a problem for people trusting .nz
you really need to add a couple of queries. 1b) Are 2048 bit keys secure ENOUGH for a 5Y rolled KSK?
My answer to 1 is "I can't be sure, opinions vary, but NZRS has consulted experts in this field and they seem to suggest that it a viable option at present."
My answer is .. Absolutly - given the current trend on crypto research and the fact that we expect to change the material more often than a five year cycle.
My answer to 2 is "I believe that people will view the .nz DNSSEC implmentation as less secure if it has a smaller bit-length KSK. Regardless of whether they are right or wrong, that will be the public perception."
Esp. when folks like you/me continue to trot out the mis-directed presumption that size is the only thing that matters.
What I do know for sure is, if you implement 2048 bit keys as you suggested in an earlier email, both of these questions are moot. Dean
Er, not really - then some wingnut is going to start harping on 4096bit keys. The correct tactic is to understand the options for the most robust security posture, not just bigger keys is better. (which seemed to be part of the rest of this thread - a good discussion btw) /bill
![](https://secure.gravatar.com/avatar/715ece208307fc1ef4ff37a049fa787e.jpg?s=120&d=mm&r=g)
And for anyone who's thinking TL;DR here's the summary from xkcd;
http://xkcd.com/538/
A security process is only as strong as it's weakest link and if you have a
nice strong chain overall there's no point forging one particularly massive
link somewhere along the way just because you happened to have surplus steel
or you think it makes the chain look intimidating.
Is this a fair summary?
On 10 June 2011 02:55,
On Thu, Jun 09, 2011 at 11:38:47PM +1200, Dean Pemberton wrote:
There have been some well presented arguments for both 1280 and 2048 bit keys today. My initial query was to why 1280 keys had been chosen over 2048 bit keys, and that this seemed to be a departure from accepted practice. Both Sebastian and yourself have provided an enlightening discussion of the thought process behind this. You've even pulled in the BigGuns(tm).
accepted practice is driven by vendor defaults and recomendations, not always grounded in good practice. e.g. accepted != good.
1280 bit keys ARE less secure than 2048 bit keys, and as you point out, both of these are less secure than 4096 bit keys.
what do you mean by "secure"? harder to break, with all other factors being equal? perhaps true. -BUT- there is such a thing as "overkill" ... do you really need a 8192bit key for a DHCP lease lasting 15minutes? I am not persuaded that the information moved in that 15min interval needs a 20year protection window. What was missing in the presumptive key selection was the temporal lifespan of the key. As mentioned earlier, a 1280/1 key might be stronger than a 2048/5 key.
So I believe that there are two issues here...
1) Are 1280 bit keys secure ENOUGH for a 1Y rolled KSK? 2) Is having a bit length smaller than the majority of other DNSSEC TLDs going to be a problem for people trusting .nz
you really need to add a couple of queries.
1b) Are 2048 bit keys secure ENOUGH for a 5Y rolled KSK?
My answer to 1 is "I can't be sure, opinions vary, but NZRS has consulted experts in this field and they seem to suggest that it a viable option at present."
My answer is .. Absolutly - given the current trend on crypto research and the fact that we expect to change the material more often than a five year cycle.
My answer to 2 is "I believe that people will view the .nz DNSSEC implmentation as less secure if it has a smaller bit-length KSK. Regardless of whether they are right or wrong, that will be the public perception."
Esp. when folks like you/me continue to trot out the mis-directed presumption that size is the only thing that matters.
What I do know for sure is, if you implement 2048 bit keys as you suggested in an earlier email, both of these questions are moot. Dean
Er, not really - then some wingnut is going to start harping on 4096bit keys. The correct tactic is to understand the options for the most robust security posture, not just bigger keys is better. (which seemed to be part of the rest of this thread - a good discussion btw) /bill _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/7ae5fb6e0b5212fa4afaadbe221e3540.jpg?s=120&d=mm&r=g)
thats one way to look at it. :) /bill On Fri, Jun 10, 2011 at 06:26:22AM +1200, Bruce Kingsbury wrote:
And for anyone who's thinking TL;DR here's the summary from xkcd;
A security process is only as strong as it's weakest link and if you have a nice strong chain overall there's no point forging one particularly massive link somewhere along the way just because you happened to have surplus steel or you think it makes the chain look intimidating.
Is this a fair summary?
On 10 June 2011 02:55,
wrote: On Thu, Jun 09, 2011 at 11:38:47PM +1200, Dean Pemberton wrote:
There have been some well presented arguments for both 1280 and 2048 bit keys today. My initial query was to why 1280 keys had been chosen over 2048 bit keys, and that this seemed to be a departure from accepted practice. Both Sebastian and yourself have provided an enlightening discussion of the thought process behind this. You've even pulled in the BigGuns(tm).
accepted practice is driven by vendor defaults and recomendations, not always grounded in good practice. e.g. accepted != good.
1280 bit keys ARE less secure than 2048 bit keys, and as you point out, both of these are less secure than 4096 bit keys.
what do you mean by "secure"? harder to break, with all other factors being equal? perhaps true. -BUT- there is such a thing as "overkill" ... do you really need a 8192bit key for a DHCP lease lasting 15minutes? I am not persuaded that the information moved in that 15min interval needs a 20year protection window. What was missing in the presumptive key selection was the temporal lifespan of the key. As mentioned earlier, a 1280/1 key might be stronger than a 2048/5 key.
So I believe that there are two issues here...
1) Are 1280 bit keys secure ENOUGH for a 1Y rolled KSK? 2) Is having a bit length smaller than the majority of other DNSSEC TLDs going to be a problem for people trusting .nz
you really need to add a couple of queries.
1b) Are 2048 bit keys secure ENOUGH for a 5Y rolled KSK?
My answer to 1 is "I can't be sure, opinions vary, but NZRS has consulted experts in this field and they seem to suggest that it a viable option at present."
My answer is .. Absolutly - given the current trend on crypto research and the fact that we expect to change the material more often than a five year cycle.
My answer to 2 is "I believe that people will view the .nz DNSSEC implmentation as less secure if it has a smaller bit-length KSK. Regardless of whether they are right or wrong, that will be the public perception."
Esp. when folks like you/me continue to trot out the mis-directed presumption that size is the only thing that matters.
What I do know for sure is, if you implement 2048 bit keys as you suggested in an earlier email, both of these questions are moot. Dean
Er, not really - then some wingnut is going to start harping on 4096bit keys. The correct tactic is to understand the options for the most robust security posture, not just bigger keys is better. (which seemed to be part of the rest of this thread - a good discussion btw) /bill _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
Awwww. That hurts Bruce, Given that that cartoon is printed out and hanging up in my cube at work it hurts to have it pulled out now =) I agree with that sentiment 100%, and I hope it serves to illustrate why my initial post had many more points about things like Site location and security Personnel Security etc etc etc Please don't confuse discussing key length with being solely focussed on it. Dean On 10/06/11 6:26 AM, Bruce Kingsbury wrote:
And for anyone who's thinking TL;DR here's the summary from xkcd;
A security process is only as strong as it's weakest link and if you have a nice strong chain overall there's no point forging one particularly massive link somewhere along the way just because you happened to have surplus steel or you think it makes the chain look intimidating.
![](https://secure.gravatar.com/avatar/eb9b49f64048b04c98e7ca65054fbe53.jpg?s=120&d=mm&r=g)
On Fri, Jun 10, 2011 at 06:57, Dean Pemberton
Please don't confuse discussing key length with being solely focussed on it.
I think the way the discussion, temporarily, narrowed on an easily compared numeric issue, is testament to the lure of simple comparisons and drives the perception/political side of the argument. Even we are not immune to the siren call. One other point, if "someone announced today that they could factor a 1024 bit key in just 1 second" it would not be the result of Moore's Law, and clearly illustrates the speaker is not "under the impression that advances in cryptographic key breaking only ever proceed at a linear pace."
Dean
Hamish. -- http://tr.im/HKM
![](https://secure.gravatar.com/avatar/155f1500e005d1fbbaf246ed5bce9277.jpg?s=120&d=mm&r=g)
Agreed, There are a lot of very valid points in Dean's first post. No point in having a 4096bit key if it ends up on a flash drive dropped out of a laptop bag on Lambton quay
--
Tristram Cheer
Network Architect
Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985
Fax. | tristram.cheer(a)ubergroup.co.nz | www.ubergroup.co.nz
PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd
-----Original Message-----
From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Hamish MacEwan
Sent: Friday, 10 June 2011 9:03 a.m.
To: Dean Pemberton
Cc: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
On Fri, Jun 10, 2011 at 06:57, Dean Pemberton
Please don't confuse discussing key length with being solely focussed on it.
I think the way the discussion, temporarily, narrowed on an easily compared numeric issue, is testament to the lure of simple comparisons and drives the perception/political side of the argument. Even we are not immune to the siren call. One other point, if "someone announced today that they could factor a 1024 bit key in just 1 second" it would not be the result of Moore's Law, and clearly illustrates the speaker is not "under the impression that advances in cryptographic key breaking only ever proceed at a linear pace."
Dean
Hamish. -- http://tr.im/HKM _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/91d2b3948ed1461038cf9bbf79219b8b.jpg?s=120&d=mm&r=g)
On 10/6/11 6:26 AM, "Bruce Kingsbury"
And for anyone who's thinking TL;DR here's the summary from xkcd;
Very true, and the reason I'm far less interested in deeper background checks on the officers and more in favour of processes that reduce the vulnerability to the suborning of a single or even two officers. I don't, for instance, want us to suggest that the officers need to be cleared to <the opposite of bottom> s*cret (I'm assuming that this list goes to some people who work for agencies where the mere appearance of that plain text will cause them problems). The recent shenanigans around New Zealand's most senior defence scientist, who presumably had at least such a background check, should ably demonstrate the flaws in that approach. -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 555 500 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
On 10/06/11 9:51 AM, Michael Newbery wrote:
Very true, and the reason I'm far less interested in deeper background checks on the officers and more in favour of processes that reduce the vulnerability to the suborning of a single or even two officers.
That seems as good a time as any to address one of the other issues. You mentioned in one of your earlier emails "What ensures that the processes are followed?" I've also suggested that there be TCRs at least present if not involved. Might it help if Jay/Sebastian posted as much detail as they feel comfortable with around the proposed processes (a script would be great) and then people can give feedback. Regards Dean
![](https://secure.gravatar.com/avatar/b21b7c7d0abf3ca77426817e1d214cf5.jpg?s=120&d=mm&r=g)
On 06/10/2011 01:27 PM, Dean Pemberton wrote:
On 10/06/11 9:51 AM, Michael Newbery wrote:
Very true, and the reason I'm far less interested in deeper background checks on the officers and more in favour of processes that reduce the vulnerability to the suborning of a single or even two officers.
That seems as good a time as any to address one of the other issues.
You mentioned in one of your earlier emails "What ensures that the processes are followed?" I've also suggested that there be TCRs at least present if not involved.
Might it help if Jay/Sebastian posted as much detail as they feel comfortable with around the proposed processes (a script would be great) and then people can give feedback.
By the moment we are not comfortable sharing the Key Generation script because is not in Production-Ready state. We will publish the document before generating the keys though. I'd like to clarify the Key Generation process, from its inception, includes the presence of External Witnesses. This is inspired by the Key Ceremony script used for the root zone, but with the adjustment needed to suit our needs and specific deployment. Cheers,
Regards Dean
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
Hi Bill, On 10/06/11 2:55 AM, bmanning(a)vacation.karoshi.com wrote:
Esp. when folks like you/me continue to trot out the mis-directed presumption that size is the only thing that matters.
I think you're being a bit unfair here, given that my initial post had a single 'query' regarding key length and many more points regarding site security, personnel, procedures etc. There is no way that I'm proposing that keysize is the single biggest factor here. I'd love to be able to start talking about those other things. Take that as a segue if you like... Dean
![](https://secure.gravatar.com/avatar/7ae5fb6e0b5212fa4afaadbe221e3540.jpg?s=120&d=mm&r=g)
On Fri, Jun 10, 2011 at 06:51:14AM +1200, Dean Pemberton wrote:
Hi Bill,
On 10/06/11 2:55 AM, bmanning(a)vacation.karoshi.com wrote:
Esp. when folks like you/me continue to trot out the mis-directed presumption that size is the only thing that matters.
I think you're being a bit unfair here, given that my initial post had a single 'query' regarding key length and many more points regarding site security, personnel, procedures etc. There is no way that I'm proposing that keysize is the single biggest factor here.
I'd love to be able to start talking about those other things. Take that as a segue if you like...
Dean
repuation seems like a significant factor to me. its either "we all love Father Christmas" cult of personality or there is a problem with the limited size cabal of cronies who are rigging the system w/o our knowledge or consent... ie throw the ruffians out and put in someone "I" can trust. and no the police are not universally trusted. /bill
![](https://secure.gravatar.com/avatar/c3bb71a7964913601d580b680b2b689c.jpg?s=120&d=mm&r=g)
On 09/06/11 15:37, Ewen McNeill wrote:
If anything, to echo Jay, this seems like "over engineering" to solve a perceived problem that I'm not really convinced will exist in real life for more than a trivial amount of time. If it turns out that there is a genuine need at the initial deployment to allow more time for people to deal with the packet fragmentation/no-TCP issue, I'd probably live with "1280-bit ZSK in first year, raised to 1536-bit/2048-bit after 12 months" as a policy. But it's not clear to me that even that is needed.
I'd add the observation that for heavy DNS, fall back to TCP needs to be an absolute last resort. TCP fall-back has three major drawbacks: 1. It puts a lot more load on the name server as it has to keep state. Stateful things are inherently vulnerable to denial of service attacks by overflowing state tables. (Maybe Geoff Huston's "stateless TCP DNS" needs more research ...) 2. There are delays setting up the TCP session. A UDP transaction's takes only one RTT to complete (assuming processing time is negligible). A TCP response requires a three way handshake, plus data, plus session close, or three times RTT. Add another RTT for the truncated UDP response. If that DNS server is over 250 ms away (e.g. eastern USA, or Europe), that's a full second to get a response; a few referrals and those seconds start adding up. 3. TCP fall-back only occurs on receiving a truncated response (TC bit set). 3. is a killer if a fragmentation black-hole exists. If a fragmented packet does not (fully) arrive, the DNS resolver gets no indication that it needs to fall back to TCP. Failure to get the response will cause it to retry another server, not fall back to TCP, which if the fragmentation black-hole is nearby means you just don't get a response. And of course there are still idiots configuring firewalls who think DNS only works on UDP. I haven't done all the numbers, but I have to say that avoidance of both fragmentation and truncation needs to be a goal in setting key sizes. Gut feel is that one should be aiming for layer 3 packet lengths of < 1400 octets, possibly less to allow for tunneling, PPPoE and other not-quite-1500 MTU channels. -- don
![](https://secure.gravatar.com/avatar/34a7655fc8589ac784345a27d441918e.jpg?s=120&d=mm&r=g)
This is possibly somewhat academic given Jay's recent post to the effect that "we should do 2048-bit KSK because it is common practice", but... On 2011-06-09 18:04 , Don Stokes wrote:
I'd add the observation that for heavy DNS, fall back to TCP needs to be an absolute last resort.
I agree that DNS-via-TCP should be (designed to be) a rare occurrence, because it performs... poorly. Especially when used only after timeout-on-UDP. I'd definitely have a concern if the _Z_SK signatures were pushing regularly fetched RR+sigs over the de facto standard 1500-byte boundary, for the reasons that you list. But AFAIK everyone seems happy that the ZSK should be (much) smaller, and rolled frequently, and indeed that was one of the major motivations for the KSK/ZSK split. So few, if any, RR+sigs should be pushed over 1500-bytes by the ZSK signatures as I understand it. (Although I understand most/all will end up going over the historic 512-byte boundary.) But per the figures provided by Sebastian it's the: (a) (KS + ZS) key rollover time, where (b) the DNSKEY RR is fetched with all the pubkey/signatures, from (c) a > 1280-byte KSK that pushes the packet over the usually-designed-in "can pass 1500 bytes because the whole world is ethernet" limit, into the realms of could be UDP fragments, might not work, might need to retry as TCP. So not only should DNSKEY RRs be relatively infrequently on the wire (since they can be cached for relatively long TTL), but only DNSKEY RRs in certain rare situations (multiple key rollover), even with 2048-bit KSK, will end up big enough to be a problem. And anyone caught out by this will be caught out by dozens of other TLDs anyway, so will hopefully eventually get a clue that "the Internet is broken" is actually an issue close(r) to them. Ewen PS: Peter Gutmann is of course completely right that even at 1280-bits the KSK is by no means the weakest point to compromise. Many other points would be much easier to compromise. Including, eg, injecting faked data via a less-secure registrar (as one of the SSL CAs was compromised recently). However the KSK bit size is on the sticker on the outside, and easily measurable, so is likely to be a point of comparison. Security of authorised registrars is much harder to quantify/police.
![](https://secure.gravatar.com/avatar/f746745142a8afa6d5548376855e963c.jpg?s=120&d=mm&r=g)
On 06/09/2011 11:23 PM, Ewen McNeill wrote:
However the KSK bit size is on the sticker on the outside, and easily measurable, so is likely to be a point of comparison. Security of authorised registrars is much harder to quantify/police.
This last statement is of particular interest to me. As an authorised Registrar, so far I have only been considering the technology side of DNSSEC. Are there going to be any procedural or process specifications/guidelines that registrars are going to be required to implement/meet ? For a small player, is it even going to be possible to meet them ? Glen -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen and Rosanne Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph: +64 6 357 8168, Fax: +64 6 357 8165, Mob: +64 27 542 4015 "A Ministry specialising in providing low-cost professional Internet Services to NZ Christian Churches, Ministries and Organisations"
![](https://secure.gravatar.com/avatar/9ae8bd383bb37181ac8e4fd7850ae6c3.jpg?s=120&d=mm&r=g)
On 06/09/2011 11:23 PM, Ewen McNeill wrote:
However the KSK bit size is on the sticker on the outside, and easily measurable, so is likely to be a point of
Having waded through this thread, I am going to offer an opinion - an opinion that, thus far has served me well. If you are going to go through the hassle of deploying encryption; whether it be for security, or trust - then you might as well go through the effort of ensuring that use the highest available key sizing available. I know there are a lot of technical and performance issues to consider, but as I said this little mantra makes sense based purely on increasing computational power gains. Why settle for something that may be compromised in 5 years when you can get 10 years to begin with. -JoelW
![](https://secure.gravatar.com/avatar/7ae5fb6e0b5212fa4afaadbe221e3540.jpg?s=120&d=mm&r=g)
On Fri, Jun 10, 2011 at 07:46:24AM +1200, Joel Wiramu Pauling wrote:
On 06/09/2011 11:23 PM, Ewen McNeill wrote:
However the KSK bit size is on the sticker on the outside, and easily measurable, so is likely to be a point of
Having waded through this thread, I am going to offer an opinion - an opinion that, thus far has served me well.
If you are going to go through the hassle of deploying encryption; whether it be for security, or trust - then you might as well go through the effort of ensuring that use the highest available key sizing available.
I know there are a lot of technical and performance issues to consider, but as I said this little mantra makes sense based purely on increasing computational power gains. Why settle for something that may be compromised in 5 years when you can get 10 years to begin with.
-JoelW
Well - thats an easy answer for me: ) bigger keys == bigger packets == more cost of bandwidth ) bigger keys == bigger packets == more cost for CPU ) bigger keys -WITH THE SAME ALGORITHM- are vulnerable to cracks in the algo. So 10years is likely worthless for me. YMMV of course. /bill
![](https://secure.gravatar.com/avatar/9ae8bd383bb37181ac8e4fd7850ae6c3.jpg?s=120&d=mm&r=g)
On 10 June 2011 07:51,
Well - thats an easy answer for me:
) bigger keys == bigger packets == more cost of bandwidth ) bigger keys == bigger packets == more cost for CPU ) bigger keys -WITH THE SAME ALGORITHM- are vulnerable to cracks in the algo. So 10years is likely worthless for me.
All valid arguments to be sure. But... then again, this is roughly synonymous with the "why bother locking your front door..." argument.
![](https://secure.gravatar.com/avatar/7ae5fb6e0b5212fa4afaadbe221e3540.jpg?s=120&d=mm&r=g)
On Fri, Jun 10, 2011 at 08:07:22AM +1200, Joel Wiramu Pauling wrote:
On 10 June 2011 07:51,
wrote: Well - thats an easy answer for me:
) bigger keys == bigger packets == more cost of bandwidth ) bigger keys == bigger packets == more cost for CPU ) bigger keys -WITH THE SAME ALGORITHM- are vulnerable to cracks in the algo. So 10years is likely worthless for me.
All valid arguments to be sure. But... then again, this is roughly synonymous with the "why bother locking your front door..." argument.
right. do you get a lock that is "good enough" or are you going to spend the money/effort to maintain a 3m thick blast door while not worrying about the flimsy lath & stucco walls? As young Dean points out, the focus on the keysize sticker on the side'o'thebox is misguided. a well designed crypto/key management system - with a credible understaning of the actual threats - will (nearly) always pick the correct algo & keysize needed for the job. //bill
![](https://secure.gravatar.com/avatar/155f1500e005d1fbbaf246ed5bce9277.jpg?s=120&d=mm&r=g)
I get that Kiwi's have to have to things differently downunder, It's part of our DNA but if the key size is important cryptographically or not is largely irrelevant. If the rest of the world has chosen 2048bit keys and a longer key lifetime then .nz should run with 2048bit keys if there is no valid technical reason not to, The rest of the world has chosen 2048bit so cpu time/packet sizes is a moot enough point for them to chose it. I've largely ignored DNSSEC for the past 3-4 years as it didn't really seem to have any traction but this seems to have changed, I will look at implementing it again on our network but I'm personally not going to dig into the crypto side of it too much as I imagine a lot of IT people who implement it won't either. From a lay person perspective a 1280bit key is weaker than a 2048bit key, A lay person isn't going to look into it too much to see the key lifetime is different etc etc they will just see we run a smaller number than the rest of the world and naturally think it's weaker which may or may not be true. If the energy, effort and cost of buying a good enough lock or getting a 3m thick blast door is near enough to the same then I will go with the blast door. It's only when the cost to implement is different enough between the two options that I would consider buying a good enough lock. Cosmetic it may be but the people who have to trust DNSSEC aren't the crypto geeks who designed it. Cheers -- Tristram Cheer Network Architect Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 Fax. | tristram.cheer(a)ubergroup.co.nz | www.ubergroup.co.nz PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of bmanning(a)vacation.karoshi.com Sent: Friday, 10 June 2011 8:14 a.m. To: Joel Wiramu Pauling Cc: bmanning(a)vacation.karoshi.com; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet On Fri, Jun 10, 2011 at 08:07:22AM +1200, Joel Wiramu Pauling wrote:
On 10 June 2011 07:51,
wrote: Well - thats an easy answer for me:
) bigger keys == bigger packets == more cost of bandwidth ) bigger keys == bigger packets == more cost for CPU ) bigger keys -WITH THE SAME ALGORITHM- are vulnerable to cracks in the algo. So 10years is likely worthless for me.
All valid arguments to be sure. But... then again, this is roughly synonymous with the "why bother locking your front door..." argument.
right. do you get a lock that is "good enough" or are you going to spend the money/effort to maintain a 3m thick blast door while not worrying about the flimsy lath & stucco walls? As young Dean points out, the focus on the keysize sticker on the side'o'thebox is misguided. a well designed crypto/key management system - with a credible understaning of the actual threats - will (nearly) always pick the correct algo & keysize needed for the job. //bill _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/b0b88c827aa8d6638c4f07c22ccd5137.jpg?s=120&d=mm&r=g)
Perhaps we need a new marketing and PR thread then. :) The issue does not seem to be a technical one, but one of human perception. -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tristram Cheer ...
From a lay person perspective a 1280bit key is weaker than a 2048bit key, A lay person isn't going to look into it too much to see the key lifetime is different etc etc they will just see we run a smaller number than the rest of the world and naturally think it's weaker which may or may not be true.
....
![](https://secure.gravatar.com/avatar/7b47dffbef879b2144119dd2c507a1c4.jpg?s=120&d=mm&r=g)
On 9/06/2011, at 11:23 PM, Ewen McNeill wrote:
PS: Peter Gutmann is of course completely right that even at 1280-bits the KSK is by no means the weakest point to compromise. Many other points would be much easier to compromise. Including, eg, injecting faked data via a less-secure registrar (as one of the SSL CAs was compromised recently). However the KSK bit size is on the sticker on the outside, and easily measurable, so is likely to be a point of comparison. Security of authorised registrars is much harder to quantify/police.
X.509 vendors have gone to extraordinary lengths to get people to look at the bit size as a sticker on the box and still nobody does. I can guarantee that nobody will look at the KSK size for the same reasons. This conversation is possibly the only discussion that will ever take place on this issue. The best result for DNSSEC is if it becomes ubiquitous, standard practice and just works. Any attempt at making it into something bigger than that will fade quickly - it simply is not high profile enough. regards Jay
_______________________________________________ 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
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
On 10/06/2011 9:32 a.m., Jay Daley wrote:
X.509 vendors have gone to extraordinary lengths to get people to look at the bit size as a sticker on the box and still nobody does. I can guarantee that nobody will look at the KSK size for the same reasons. This conversation is possibly the only discussion that will ever take place on this issue.
SSL vendors spend energy marking brand and establishing that their brand is more secure than others. Verisign is the most secure - why? Because they told me that. Verisign is also the most expensive and so much so that I don't even bother to look at the product and price for my customers because I know it will be out of the budget. How do I know this? Because industry people have told me that RapidSSL is cheaper and within my budget. Correct - there is no logic here. All my assumptions are based on nothing of substance. The technical merit has nothing to do with the process for SSL at all for some. My concern is about global perception of the .nz space, hence why I agree with Dean. D
![](https://secure.gravatar.com/avatar/abc7d0f346efeceea83a83e29ac1e4a6.jpg?s=120&d=mm&r=g)
On Thu, 09 Jun 2011 at 15:09:41 +1200, Sebastian Castro wrote:
We investigated different KSK sizes and their effect in response sizes for a DNSKEY query. The 512-byte limit was a concern before initial DNSSEC deployment, but the system seems to be coping well. The main concern is about clients supporting EDNS but being unable to receive fragmented packets. So we aimed to have a DNSKEY response below the 1420-bytes (Ethernet MTU - headers).
I was reading up about BGPSEC and I came across an interesting presentation by K. Sriram from NIST that shows how using ECDSA can reduce the RIB size by more than half compared to RSA (if BGPSEC ever happens): http://www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf This got me thinking about packet size and DNSSEC, and it seems that the IETF have already looked at this, although the draft has expired: http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 It seems that this would go a long way to reducing response size while maintaining a politically and technically acceptable level of security. Hopefully the draft comes back to life or is replaced by something better. Nigel
![](https://secure.gravatar.com/avatar/f4bf13e5b2c22bf20c3911677369008e.jpg?s=120&d=mm&r=g)
On 2011-06-14, at 21:48, Nigel Roberts wrote:
http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04
It seems that this would go a long way to reducing response size while maintaining a politically and technically acceptable level of security. Hopefully the draft comes back to life or is replaced by something better.
I believe there is still a good amount of enthusiasm for using new ECC algorithms in DNSSEC. I'm no cryptographer, but I believe GOST is an example of such an algorithm (see RFC 5933). GOST is supported in recent releases of BIND9, NSD and Unbound. If you want to learn more, go and browse the dnsext mailing list archives (or ask on that list). However, the point that I wanted to make was that we have now had numerous examples of enlarged response size due to the deployment of DNSSEC. We've seen (accidental) massive increase in the use of TCP transport in ORG due to a TTL mishap on ORG's SOA resource record, and we've also tested the impact of large priming query responses in the root zone. I am not aware of any harm to any client that resulted from either of these (that is, nothing was noted publicly or, in the case of the root zone, publicly or privately). So while I think it's always prudent to be conservative with the client population, especially in the case of the DNS where the client population is impossible to characterise accurately in detail, I don't think response size ought necessarily to be the primary consideration when choosing signing parameters (including key size). Joe
![](https://secure.gravatar.com/avatar/1ff2336f608bb376d1ddb3be51005668.jpg?s=120&d=mm&r=g)
On 9/06/2011, at 1:10 PM, Jay Daley wrote:
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.
I haven't read the rest of this post in detail but this caught my eye. I'm not sure that packet size is a problem when other registries are doing 2048bit. Same for sig verification for that matter - if 90% of registries are 2048bit, do we really save the world that much CPU? What's the CPU difference between no verification, 1280bit, and 2048bit? If it is for example 100 cycles to do no validation, 10000 for 1280bit validation, and 11000 for 2048bit validation, we're talking about a CPU step up of 100x or 110x. Seems pretty insignificant at that point - especially when most other registries are doing 2048bit, the difference between CPU required for .nz's decision between 1280 and 2048 gets even smaller.. -- Nathan Ward
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
On 9/06/11 1:10 PM, Jay Daley wrote:
I will respond to the rest of your points later!
Cool - so another 24 hours and we're still making cracking progress. I'm really pleased with the level of discussion on this. By the end of this I really believe that we're going to have a process that we can all stand behind and be proud off! Some of these issues seem well on the way to being sorted. . Document Management . Audit . Personnel . Key Length Some other ones don't seem to have moved anywhere yet: . Trusted community representatives . Site Security
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/aa4d85835756cb8d2ff2b443721b3e45.jpg?s=120&d=mm&r=g)
Hi, as a long time lurker of this list and know little about root dnssec ops , should .NZ folks need any help or need suggestions on anything related to ceremonies or KMF building/operating etc, feel very free to ask on or off-list. mehmet On Jun 14, 2011, at 10:20 AM, Dean Pemberton wrote:
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.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/ed969b142382fddf82a63b5ab452f316.jpg?s=120&d=mm&r=g)
On 15/06/11 10:18 AM, "Mehmet Akcin"
Hi,
as a long time lurker of this list and know little about root dnssec ops , should .NZ folks need any help or need suggestions on anything related to ceremonies or KMF building/operating etc, feel very free to ask on or off-list.
I guess the next question what are .nz registrar's/ISPs going to do regarding DNSSEC. As I work for a Registrar/ISP I have spent the last week working out a prototype on a couple of name servers running DNSSEC, signing, rolling, sending to the .nz registery etc etc and "it works" but there is a lot of planning and automation that has been done before it can go anywhere near production. What are people going to run as authoritative servers for DNSSEC ? Bind? PowerDNS ? OpenDNSSEC ? Windows? Other Commercial Program? Are ISP's going to turn on DNSSEC/Validation on their own Recursive Name Servers as well? Lots of other questions but if any other Registrar's/ISP want to discuss regarding what they are going I will listen. Thanks Craig
![](https://secure.gravatar.com/avatar/f4bf13e5b2c22bf20c3911677369008e.jpg?s=120&d=mm&r=g)
On 2011-06-14, at 19:44, Craig Whitmore wrote:
What are people going to run as authoritative servers for DNSSEC ? Bind? PowerDNS ? OpenDNSSEC ? Windows? Other Commercial Program?
I've had some success with BIND9 and NSD serving signed zones. The root servers use a mixture of BIND9 and NSD, for example, as does (I believe) the DNS infrastructure for .ORG. OpenDNSSEC is a signer, not a nameserver: it produces zones which you then need an authority-only nameserver to serve. I haven't been paying attention to PowerDNS, but I know Bert had mentioned working on DNSSEC support. (Oh look, top hit on google ?q=powerdns+dnssec, http://wiki.powerdns.com/trac/wiki/PDNSSEC). No idea about Windows. In the interests of fairness, you should bing that yourself.
Are ISP's going to turn on DNSSEC/Validation on their own Recursive Name Servers as well?
Several large ISP and University networks in the world have done so. DNSSEC is ultimately a tool to protect the cache from poisoning attacks, so turning on DNSSEC validation on those servers does make a certain amount of sense. At the end of the day, if nobody validates responses then signing is a bit of a waste of time. I might mention that validation at this (relatively) early period of DNSSEC adoption is going to probably involve giving more attention to the recursive server than you are used to, and more than we might hope will be required in the future as authority-server operators gain more operational experience with signed zones.
Lots of other questions but if any other Registrar's/ISP want to discuss regarding what they are going I will listen.
Joe
![](https://secure.gravatar.com/avatar/f746745142a8afa6d5548376855e963c.jpg?s=120&d=mm&r=g)
On 06/15/2011 11:44 AM, Craig Whitmore wrote:
I guess the next question what are .nz registrar's/ISPs going to do regarding DNSSEC.
An earlier posting in this thread, by me, got no feedback so I will raise the issue again. The technology is only one part of the equation. What, if anything, is going to be required by DNS Operators ( who may or may not be Registrars ) with respect to processes and procedures associated with signing, key management, auditing etc.
As I work for a Registrar/ISP I have spent the last week working out a prototype on a couple of name servers running DNSSEC, signing, rolling, sending to the .nz registery etc etc and "it works" but there is a lot of planning and automation that has been done before it can go anywhere near production.
My first experiment with this a few months ago was less than successful, I am using BIND9 and turning on some of the DNSSEC features resulted in some zones no longer being accessible. Why ? No idea. Did I do everything right ? I thought so but based on the result, probably not.
Lots of other questions but if any other Registrar's/ISP want to discuss regarding what they are going I will listen.
I too would value any ideas, experiences, how-to and how-not-to's that others have got. Hopefully getting the DNSSEC infrastructure at the Regsitrar/DNS Operator level can become almost cook-book. As Joe has pointed out, without validation, signing zones is a bit pointless. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 27 542 4015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."
![](https://secure.gravatar.com/avatar/ed969b142382fddf82a63b5ab452f316.jpg?s=120&d=mm&r=g)
On 15/06/11 1:48 PM, "Glen Eustace"
On 06/15/2011 11:44 AM, Craig Whitmore wrote:
I guess the next question what are .nz registrar's/ISPs going to do regarding DNSSEC.
An earlier posting in this thread, by me, got no feedback so I will raise the issue again. The technology is only one part of the equation. What, if anything, is going to be required by DNS Operators ( who may or may not be Registrars ) with respect to processes and procedures associated with signing, key management, auditing etc.
I presume not any less than the NZRS is doing.
My first experiment with this a few months ago was less than successful, I am using BIND9 and turning on some of the DNSSEC features resulted in some zones no longer being accessible. Why ? No idea. Did I do everything right ? I thought so but based on the result, probably not.
Yes I had the same/similar problem when following the instructions on bind 9.7 . They changed quite a few things in different versions of 9.7 with different options in all these versions. I upgraded to 9.8 and it works fine with these important extra settings only. dnssec-enable yes; dnssec-validation auto; dnssec-lookaside auto; This will use the the lookaside (dlv.isc.org) as well as the root servers. So when you do this looking up a domain with broken DNSSEC (like spam.co.nz is at the moment) syslog: error (broken trust chain) resolving 'www.spam.co.nz/A/IN': 114.23.33.131#53 nslookup www.spam.co.nz ** server can't find www.spam.co.nz: SERVFAIL So people have to be careful in the future (right now) not to break your DNSSEC or people might not be able to see you.
I too would value any ideas, experiences, how-to and how-not-to's that others have got. Hopefully getting the DNSSEC infrastructure at the Regsitrar/DNS Operator level can become almost cook-book. As Joe has pointed out, without validation, signing zones is a bit pointless.
My Experience/howto with powerdns and the NZRS stuff is @ http://www.geekzone.co.nz/LennonNZ/7692 I've updated it over time when I work out how things actually work/should work. Thanks Craig
![](https://secure.gravatar.com/avatar/4f215ac6755aff3820533ec4ffbe6aa8.jpg?s=120&d=mm&r=g)
I'm confident we'll see answers here to these questions so that I can go back to the DNCL Board and report that this process has the support of the technical community.
![](https://secure.gravatar.com/avatar/4f215ac6755aff3820533ec4ffbe6aa8.jpg?s=120&d=mm&r=g)
So should we measuring trust against external criteria like this? It doesn't have to be this process exactly of course. https://www.iana.org/dnssec/systrust
![](https://secure.gravatar.com/avatar/58e0d5576ead0e5fa75d77b10045fbbe.jpg?s=120&d=mm&r=g)
On 18/06/2011 7:18 p.m., Andy Linton wrote:
So should we measuring trust against external criteria like this? It doesn't have to be this process exactly of course.
Yes. Keith Davidson
![](https://secure.gravatar.com/avatar/2de8fd11bf59d39a4c12b8bd4b0e93c1.jpg?s=120&d=mm&r=g)
It certainly couldn't hurt. Have any other DNSSEC ccTLDs done this? Dean On 18/06/11 7:18 PM, Andy Linton wrote:
So should we measuring trust against external criteria like this? It doesn't have to be this process exactly of course.
https://www.iana.org/dnssec/systrust _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
![](https://secure.gravatar.com/avatar/173bd19b3c0f9dc235cfb84d8184c3f0.jpg?s=120&d=mm&r=g)
Ok, now that key length seems to be moving on, I have a few questions on Dean's other issues... On 8/06/2011 9:11 p.m., Dean Pemberton wrote:
Some other ones don't seem to have moved anywhere yet:
. Trusted community representatives . Site Security
Perhaps I missed it, but I don't recall seeing the Police mentioned anywhere. Smart cards held in tamper proof bags should be inspected and it strikes me that the Police are the people to be doing that on behalf of the Government and the community (public, not IT geeks). It also strikes me that the Police should be giving a sign off on site security. Lotto is verified by the Police. I'm also wondering where the Department of Internal Affairs is on this? iirc they're all over Lotto as well aren't they? Who's all over this space from the government? When it comes to representatives that most of us trust in the community it's normally a Police officer. I get the whole suggestion that your average police officer wouldn't have a clue what you're doing with a PC, but they are trained to have observation skills to note if someone is acting out of character and when to ask questions. If one of our representatives have been compromised then a Police officer is more likely to notice anything odd that I am (even given how much "The Mentalist" I watch on TV each week). Also there's an e-crimes division. Should they have people who would have some clue when it comes to what's going on at the keyboard and should have some involvement? Can we trust that those people have a level of security clearance that we should be happy with? Are those people quite so publicly visible? As with key length, there are perception issues here. D
participants (25)
-
Andy Linton
-
bmanning@vacation.karoshi.com
-
Bruce Kingsbury
-
Craig Whitmore
-
Dean Pemberton
-
Don Gould
-
Don Stokes
-
Donald Neal
-
Ewen McNeill
-
Glen Eustace
-
Hamish MacEwan
-
Jay Daley
-
Joe Abley
-
Joel Wiramu Pauling
-
Jonathan Brewer
-
Keith Davidson
-
Mark Foster
-
Mehmet Akcin
-
Michael Newbery
-
Nathan Ward
-
Nigel Roberts
-
Perry Lorier
-
Philip D'Ath
-
Sebastian Castro
-
Tristram Cheer