Discussion:
I don't trust the NZRS DNSSEC procedures... Yet
(too old to reply)
Dean Pemberton
2011-06-07 08:33:02 UTC
Permalink
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
Jay Daley
2011-06-07 09:11:26 UTC
Permalink
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
Post by Dean Pemberton
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.
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.
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.
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.
"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
"Trust us, we know what we're doing"
"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
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
Jonathan Brewer
2011-06-07 09:31:09 UTC
Permalink
Post by Dean Pemberton
. No stated archive of old versions of the document. The entire
Post by Dean Pemberton
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
-------------------------------------
Dean Pemberton
2011-06-07 10:17:06 UTC
Permalink
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
Post by Jonathan Brewer
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.
Don Gould
2011-06-07 21:43:44 UTC
Permalink
Post by Dean Pemberton
Post by Dean Pemberton
. 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
Post by Dean Pemberton
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
Don Gould
2011-06-07 10:05:57 UTC
Permalink
Post by Jay Daley
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
Dean Pemberton
2011-06-07 10:13:02 UTC
Permalink
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
Post by Jay Daley
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
Mark Foster
2011-06-07 22:15:28 UTC
Permalink
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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?
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
. 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.
Post by Dean Pemberton
. 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.
Post by Dean Pemberton
. 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.
Post by Dean Pemberton
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.)
Michael Newbery
2011-06-07 22:59:41 UTC
Permalink
Post by 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.
Andy Linton
2011-06-08 00:02:28 UTC
Permalink
On Wed, Jun 8, 2011 at 10:59 AM, Michael Newbery
Post by 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
Jay Daley
2011-06-08 00:22:24 UTC
Permalink
Post by 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?
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.
Post by Michael Newbery
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
Post by Michael Newbery
--
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
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
Jay Daley
2011-06-07 23:40:26 UTC
Permalink
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
Post by Dean Pemberton
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.
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.
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.
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.
"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
"Trust us, we know what we're doing"
"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
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
Donald Neal
2011-06-07 23:56:56 UTC
Permalink
Post by Jay Daley
[...]
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 |
Don Gould
2011-06-08 00:12:27 UTC
Permalink
Post by Donald Neal
Post by Jay Daley
[...]
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
Perry Lorier
2011-06-08 20:02:39 UTC
Permalink
Post by Donald Neal
Post by Jay Daley
[...]
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.
Dean Pemberton
2011-06-08 09:11:18 UTC
Permalink
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.
Post by Jay Daley
1. Key length
- 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.
Post by Jay Daley
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?
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
For the DNSSEC key signing we will publishing the Key Generation script and the execution log.
That's awesome. Doc should state that.
Post by Jay Daley
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.
Post by Jay Daley
6. Trusted community representatives
[Jump to later emails on this subject]
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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
Jay Daley
2011-06-09 01:10:22 UTC
Permalink
Post by Dean Pemberton
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.
Post by Dean Pemberton
Post by Jay Daley
- 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.
Post by Jay Daley
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.
Post by Dean Pemberton
RFC4641bis doesn't mention a keysize of 1280 as far as I can see.
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.pdf.

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
Post by Dean Pemberton
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
For the DNSSEC key signing we will publishing the Key Generation script and the execution log.
That's awesome. Doc should state that.
Post by Jay Daley
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.
Post by Jay Daley
6. Trusted community representatives
[Jump to later emails on this subject]
Post by Jay Daley
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.
Post by Jay Daley
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.
Post by Jay Daley
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
. Key Length
. Trusted community representatives
. Site Security
Dean
_______________________________________________
NZNOG mailing list
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
Don Gould
2011-06-09 01:49:18 UTC
Permalink
Post by Jay Daley
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...>
Post by Jay Daley
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
Jay Daley
2011-06-09 02:00:09 UTC
Permalink
Post by Don Gould
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?
Post by Don Gould
"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
Post by Don Gould
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
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
Don Gould
2011-06-09 07:34:20 UTC
Permalink
I noted the call to move to 2048...

...but I will comment on the 4096 question...
Post by Jay Daley
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.
Post by Jay Daley
Post by Don Gould
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.
Post by Jay Daley
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
Ewen McNeill
2011-06-09 01:58:49 UTC
Permalink
Hi Jay,
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.
Jay Daley
2011-06-09 02:44:44 UTC
Permalink
Hi Ewen
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.
Post by Jay Daley
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.
Post by Jay Daley
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
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
Ewen McNeill
2011-06-09 03:06:20 UTC
Permalink
Hi Jay,
Post by Jay Daley
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]
Post by Jay Daley
[...] 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
Jay Daley
2011-06-09 03:25:54 UTC
Permalink
Ewen
Post by Ewen McNeill
Hi Jay,
Post by Jay Daley
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.
Post by Ewen McNeill
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.
Post by Ewen McNeill
[reordered]
Post by Jay Daley
[...] 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
Post by Ewen McNeill
Ewen
--
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
Ewen McNeill
2011-06-09 03:36:19 UTC
Permalink
Post by Jay Daley
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
Jay Daley
2011-06-09 03:42:55 UTC
Permalink
Hi Ewen
Post by Jay Daley
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
Tristram Cheer
2011-06-09 03:40:08 UTC
Permalink
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.  | ***@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-***@list.waikato.ac.nz [mailto:nznog-***@list.waikato.ac.nz] On Behalf Of Jay Daley
Sent: Thursday, 9 June 2011 3:26 p.m.
To: Ewen McNeill
Cc: ***@list.waikato.ac.nz
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Post by Ewen McNeill
[reordered]
Post by Jay Daley
[...] 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
Post by Ewen McNeill
Ewen
--
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
Jay Daley
2011-06-09 03:47:35 UTC
Permalink
Hi Tristram
Post by Tristram Cheer
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!
Post by Tristram Cheer
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
Post by Tristram Cheer
Cheers
--
Tristram Cheer
Network Architect
Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985
PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd
-----Original Message-----
Sent: Thursday, 9 June 2011 3:26 p.m.
To: Ewen McNeill
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Post by Ewen McNeill
[reordered]
Post by Jay Daley
[...] 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
Post by Ewen McNeill
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
http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________
NZNOG mailing list
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
Sebastian Castro
2011-06-09 03:09:41 UTC
Permalink
Post by Ewen McNeill
Hi Jay,
Hi Ewen,
Post by Ewen McNeill
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.
Post by Ewen McNeill
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.
Post by Ewen McNeill
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.
Post by Ewen McNeill
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
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
Ewen McNeill
2011-06-09 03:37:47 UTC
Permalink
Hi Sebastian,
Post by Sebastian Castro
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
Sebastian Castro
2011-06-09 04:10:37 UTC
Permalink
Post by Ewen McNeill
Hi Sebastian,
Hi Ewen,
Post by Ewen McNeill
Post by Sebastian Castro
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.
Post by Ewen McNeill
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,
Post by Ewen McNeill
Ewen
_______________________________________________
NZNOG mailing list
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
Jay Daley
2011-06-09 05:44:51 UTC
Permalink
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
Jay Daley
2011-06-09 06:38:02 UTC
Permalink
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
Dean Pemberton
2011-06-09 10:07:34 UTC
Permalink
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" =)
Jay Daley
2011-06-09 11:08:41 UTC
Permalink
Hi Dean

On 9/06/2011, at 10:07 PM, Dean Pemberton wrote:

[snipped]
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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
Dean Pemberton
2011-06-09 11:38:47 UTC
Permalink
Post by Jay Daley
Post by Dean Pemberton
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
b***@vacation.karoshi.com
2011-06-09 14:55:00 UTC
Permalink
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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?
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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
Bruce Kingsbury
2011-06-09 18:26:22 UTC
Permalink
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?
Post by b***@vacation.karoshi.com
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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?
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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
http://list.waikato.ac.nz/mailman/listinfo/nznog
b***@vacation.karoshi.com
2011-06-09 18:30:01 UTC
Permalink
thats one way to look at it. :)

/bill
Post by Bruce Kingsbury
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?
Post by b***@vacation.karoshi.com
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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?
Post by Dean Pemberton
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.
Post by Dean Pemberton
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.
Post by Dean Pemberton
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
http://list.waikato.ac.nz/mailman/listinfo/nznog
Dean Pemberton
2011-06-09 18:57:14 UTC
Permalink
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
Post by Bruce Kingsbury
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.
Hamish MacEwan
2011-06-09 21:02:39 UTC
Permalink
Post by 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."
Post by Dean Pemberton
Dean
Hamish.
--
http://tr.im/HKM
Tristram Cheer
2011-06-09 21:07:33 UTC
Permalink
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.  | ***@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-***@list.waikato.ac.nz [mailto:nznog-***@list.waikato.ac.nz] On Behalf Of Hamish MacEwan
Sent: Friday, 10 June 2011 9:03 a.m.
To: Dean Pemberton
Cc: ***@list.waikato.ac.nz
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Post by 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."
Post by Dean Pemberton
Dean
Hamish.
--
http://tr.im/HKM
Dean Pemberton
2011-06-09 18:51:14 UTC
Permalink
Hi Bill,
Post by b***@vacation.karoshi.com
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
b***@vacation.karoshi.com
2011-06-09 19:39:58 UTC
Permalink
Post by Dean Pemberton
Hi Bill,
Post by b***@vacation.karoshi.com
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
Don Gould
2011-06-09 21:06:00 UTC
Permalink
Post by b***@vacation.karoshi.com
and no the police are not universally trusted.
Totally agree with that comment. Which is why they should only be a
part of the process. Some people do trust them and don't trust geeks.

D
Don Stokes
2011-06-09 06:04:00 UTC
Permalink
Post by Ewen McNeill
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
Ewen McNeill
2011-06-09 11:23:28 UTC
Permalink
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...
Post by Don Stokes
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.
Glen Eustace
2011-06-09 19:22:13 UTC
Permalink
Post by Ewen McNeill
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"
Joel Wiramu Pauling
2011-06-09 19:46:24 UTC
Permalink
Post by Ewen McNeill
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
b***@vacation.karoshi.com
2011-06-09 19:51:40 UTC
Permalink
Post by Joel Wiramu Pauling
Post by Ewen McNeill
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
Joel Wiramu Pauling
2011-06-09 20:07:22 UTC
Permalink
Post by b***@vacation.karoshi.com
) 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.
b***@vacation.karoshi.com
2011-06-09 20:13:53 UTC
Permalink
Post by Joel Wiramu Pauling
Post by b***@vacation.karoshi.com
) 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
Tristram Cheer
2011-06-09 21:03:57 UTC
Permalink
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.
Philip D'Ath
2011-06-09 21:06:38 UTC
Permalink
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-***@list.waikato.ac.nz [mailto:nznog-***@list.waikato.ac.nz] On Behalf Of Tristram Cheer
...
Jay Daley
2011-06-09 21:32:51 UTC
Permalink
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
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
Don Gould
2011-06-09 21:50:06 UTC
Permalink
Post by Jay Daley
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
Nigel Roberts
2011-06-15 01:48:26 UTC
Permalink
Post by Sebastian Castro
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
Joe Abley
2011-06-15 02:13:20 UTC
Permalink
Post by Nigel Roberts
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
Nathan Ward
2011-06-09 03:56:51 UTC
Permalink
Post by Jay Daley
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
Dean Pemberton
2011-06-09 10:11:05 UTC
Permalink
Post by Jay Daley
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
Dean Pemberton
2011-06-14 07:20:48 UTC
Permalink
Hope everyone had a good weekend.
Post by Jay Daley
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
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
For the DNSSEC key signing we will publishing the Key Generation script and the execution log.
That's awesome. Doc should state that.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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?
Post by Jay Daley
Post by Jay Daley
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.
Mehmet Akcin
2011-06-14 22:18:59 UTC
Permalink
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
Post by Dean Pemberton
Hope everyone had a good weekend.
Post by Jay Daley
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
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
For the DNSSEC key signing we will publishing the Key Generation script and the execution log.
That's awesome. Doc should state that.
Post by Jay Daley
Post by Jay Daley
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.
Post by Jay Daley
Post by Jay Daley
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?
Post by Jay Daley
Post by Jay Daley
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
http://list.waikato.ac.nz/mailman/listinfo/nznog
Andy Linton
2011-06-15 07:34:49 UTC
Permalink
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.
Andy Linton
2011-06-18 07:18:56 UTC
Permalink
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
Keith Davidson
2011-06-18 09:44:34 UTC
Permalink
Post by Andy Linton
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
Yes.

Keith Davidson
Dean Pemberton
2011-06-19 09:09:42 UTC
Permalink
It certainly couldn't hurt.
Have any other DNSSEC ccTLDs done this?

Dean
Post by Andy Linton
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
http://list.waikato.ac.nz/mailman/listinfo/nznog
Don Gould
2011-06-09 09:46:32 UTC
Permalink
Ok, now that key length seems to be moving on, I have a few questions on
Dean's other issues...
Post by Dean Pemberton
. 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
Mark Harris
2011-06-08 00:47:13 UTC
Permalink
Sigh, I always forget that default reply is not to the list.

-------- Original Message --------
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Date: Wed, 08 Jun 2011 12:41:05 +1200
From: Mark Harris <***@tracs.co.nz>
Organization: Technology Research and Consultancy Services
Post by Jay Daley
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.
What makes this more likely than one bad actor with the whole of the key
available to them? If the actors are chosen well, splitting the key
reduces risk, rather than increase it.

Which leads me to the point about trusting individuals to run the
system. You need to publish the processes by which the people will be
checked, so that the community can have trust that the individuals
chosen will always be trustworthy, because untrustworthy persons won't
make it through the process.

Any system which is built around known individuals has already failed,
when it comes to reliability. The risk is inherent.
Post by Jay Daley
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.
With respect, Jay, it's not rocket science to do this. Wikipedia offers
a good model for displaying differing versions - just restict the authors.
Post by Jay Daley
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.
And yet it's not. Adding a TCR would engender trust from the community
you need to trust you, so not adding a TCR will be the risk that is
disproportionate. ;-) Checks and balaces, Jay.

~mark
Jay Daley
2011-06-08 01:09:00 UTC
Permalink
Hi Mark
Post by Mark Harris
Sigh, I always forget that default reply is not to the list.
-------- Original Message --------
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
Date: Wed, 08 Jun 2011 12:41:05 +1200
Organization: Technology Research and Consultancy Services
Post by Jay Daley
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.
What makes this more likely than one bad actor with the whole of the key
available to them? If the actors are chosen well, splitting the key
reduces risk, rather than increase it.
My point was not that the risks of both systems are equal, just to make it clear that no system is infallible (i.e. a vulnerability in our system does not invalidate it). The balance is the appropriate thing.
Post by Mark Harris
Which leads me to the point about trusting individuals to run the
system. You need to publish the processes by which the people will be
checked, so that the community can have trust that the individuals
chosen will always be trustworthy, because untrustworthy persons won't
make it through the process.
Any system which is built around known individuals has already failed,
when it comes to reliability. The risk is inherent.
We're more than happy to publish the processes by which people are checked, as I hoped my long response to Dean made clear. It has never been our intention to operate a "trust us" registry for all the obvious reasons.
Post by Mark Harris
Post by Jay Daley
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.
With respect, Jay, it's not rocket science to do this. Wikipedia offers
a good model for displaying differing versions - just restict the authors.
Don't worry, I wasn't saying we wouldn't do it, I just wanted to check how much work was involved with our Drupal set up!
Post by Mark Harris
Post by Jay Daley
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.
And yet it's not. Adding a TCR would engender trust from the community
you need to trust you, so not adding a TCR will be the risk that is
disproportionate. ;-) Checks and balaces, Jay.
There are always process elements that we could add that would increase trust and the question is when to stop, when has the right balance been achieved? In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits.

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.

cheers
Jay
Post by Mark Harris
~mark
_______________________________________________
NZNOG mailing list
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
Mark Harris
2011-06-08 01:28:16 UTC
Permalink
Post by Jay Daley
In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits.
Well, I for one am not clear on the difference, so perhaps you could
elaborate on what you see that as being?
Jay Daley
2011-06-08 01:39:51 UTC
Permalink
Post by Jay Daley
In the case of the root the need for TCRs is clear, but in TLDs almost nobody else is using them because the TLD trust model is very different and the complications and cost they introduce outweigh the benefits.
Well, I for one am not clear on the difference, so perhaps you could elaborate on what you see that as being?
Taken from my previous email and added to a bit:

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. In .nz the single registry is fully responsible for changing the zones and distributing them and serving them.
-- In the root many of the participants are openly hostile, if not actually at war with each other. In NZ the participants are known to each other and have independent trust relationships.
-- There is no overall regulatory framework backed up by a strong regulator for the root, which .nz does have with DNCL.
-- In the root, there is no split between operations and policy, whereas in .nz this is clearly split between NZRS and 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 and have metrics governing how much downtime is allowed per server, how quickly changes propagate, how quickly we serve responses, etc.

cheers
Jay
--
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
Andy Linton
2011-06-08 02:15:41 UTC
Permalink
Damn you, list software that always does the opposite of what I want.


---------- Forwarded message ----------
From: Andy Linton <***@lpnz.org>
Date: Wed, Jun 8, 2011 at 2:14 PM
Subject: Re: [nznog] Fwd: Re: I don't trust the NZRS DNSSEC procedures... Yet
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 and have metrics governing how much downtime is allowed per server, how quickly changes propagate, how quickly we serve responses, etc.
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.

Fast, reliable, cheap - pick two.
Jay Daley
2011-06-09 00:02:32 UTC
Permalink
Post by Andy Linton
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.
Changing the .nz model for second level domains from allowing moderated domains to allowing delegated domains is a major move that would include changing just about every policy and procedure as well as significant parts of the infrastructure. I'm sure that if that were to happen there would be plenty of time to reconsider the SLA, the DPS and whatever else at that time.

cheers
Jay
Post by Andy Linton
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.
Fast, reliable, cheap - pick two.
_______________________________________________
NZNOG mailing list
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
Mark Harris
2011-06-08 02:19:21 UTC
Permalink
Post by Jay Daley
-- 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. In .nz the single registry is fully responsible for changing the zones and distributing them and serving them.
-- In the root many of the participants are openly hostile, if not actually at war with each other. In NZ the participants are known to each other and have independent trust relationships.
-- There is no overall regulatory framework backed up by a strong regulator for the root, which .nz does have with DNCL.
-- In the root, there is no split between operations and policy, whereas in .nz this is clearly split between NZRS and 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 and have metrics governing how much downtime is allowed per server, how quickly changes propagate, how quickly we serve responses, etc.
Sorry, you're talking processes, not models. You can set up the process
to be as efficient as you need it to be - that doesn't change the model.
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?"

~mark
Michael Newbery
2011-06-08 00:57:16 UTC
Permalink
Post by Jay Daley
Post by 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?
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.
Post by Jay Daley
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.
Sebastian Castro
2011-06-08 01:22:26 UTC
Permalink
Post by Michael Newbery
Post by Jay Daley
Post by 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?
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.
"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).
Post by Michael Newbery
Post by Jay Daley
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
= [mailto:] On Behalf Of =
1970-01-01 00:00:00 UTC
Permalink
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=A0| Mobile. 022 412 1985=A0
Fax. =A0| ***@ubergroup.co.nz=A0| www.ubergroup.co.nz

PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter =
https://twitter.com/#!/ubergroupltd
-----Original Message-----
From: nznog-***@list.waikato.ac.nz =
[mailto:nznog-***@list.waikato.ac.nz] On Behalf Of =
***@vacation.karoshi.com
Sent: Friday, 10 June 2011 8:14 a.m.
To: Joel Wiramu Pauling
Cc: ***@vacation.karoshi.com; ***@list.waikato.ac.nz
Subject: Re: [nznog] I don't trust the NZRS DNSSEC procedures... Yet
=20
) bigger keys =3D=3D bigger packets =3D=3D more cost of =
bandwidth
) bigger keys =3D=3D bigger packets =3D=3D 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=20
synonymous with the "why bother locking your front door..." argument.
right. =20

do you get a lock that is "good enough" or are you going to=20
spend the money/effort to maintain a 3m thick blast door while
not worrying about the flimsy lath & stucco walls? =20

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
Michael Newbery
2011-06-09 21:51:32 UTC
Permalink
Post by Bruce Kingsbury
And for anyone who's thinking TL;DR here's the summary from xkcd;
http://xkcd.com/538/
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.
Dean Pemberton
2011-06-10 01:27:28 UTC
Permalink
Post by Michael Newbery
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
Sebastian Castro
2011-06-10 01:44:31 UTC
Permalink
Post by Dean Pemberton
Post by Michael Newbery
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,
Post by Dean Pemberton
Regards
Dean
_______________________________________________
NZNOG mailing list
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
Craig Whitmore
2011-06-14 23:44:08 UTC
Permalink
Post by 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
Joe Abley
2011-06-15 00:17:41 UTC
Permalink
Post by Craig Whitmore
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.
Post by Craig Whitmore
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.
Post by Craig Whitmore
Lots of other questions but if any other Registrar's/ISP want to discuss
regarding what they are going I will listen.
Joe
Glen Eustace
2011-06-15 01:48:33 UTC
Permalink
Post by Craig Whitmore
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.
Post by Craig Whitmore
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.
Post by Craig Whitmore
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."
Craig Whitmore
2011-06-15 02:24:23 UTC
Permalink
Post by Glen Eustace
Post by Craig Whitmore
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.
Post by Glen Eustace
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.
Post by Glen Eustace
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
Loading...