2011-06-07 08:33:02 UTC
(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
Recently NZRS published their DNSSEC Practice Statement (DPS) to this
mailing list and asked us as a community to trust both them and these
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
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.
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
. 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
. Vulnerabilities are assessed by looking at logs and assessing of there
has been a problem. Some more proactive assessment might be worthwhile
. 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.
t 7| * *
r 6| * *
u 5| * * *
s 4| * * *
t 3| * * *
2| * * *
root .nz blah.govt.nz
Now lets imagine that you trust some other domain an 8/10.
8| * *
t 7| * * *
r 6| * * *
u 5| * * *
s 4| * * *
t 3| * * *
2| * * *
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.
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.