[ksk-change] FIPS-140 levels

[Richard Lamb]

Paul-

Thank you for lending your experience and voice of reason.   I agree that
from the perspective of our little community (which includes me) that fips
140 level 4 is a bit overkill.  However, in architecting this system the
target was a much broader audience with the idea that things like DANE and
other key-in-dns technologies may someday bootstrap themselves from the DNS.
Specifically I was thinking of the financial community and how to get their
buy in.  This is what brings in the AICPA/CICA and the SysTrust audit we
pass every year.  Again not because there is anything special about this
process (although I do believe it does help keep ICANN at attention), but
instead as a necessity to get the buy in from the "suits" of the world as
without their trust*, I think we only have an expensive experiment.   But I
am open to discussion and have heard many different suggestions, some very
clever, on how to better manage the root KSK to both simplify and build
trust from certain communities - but do not necessarily fit what auditors
might consider best common practice.
Happy to make happen whatever everyone decides and even have someone change
my mind that we need to make the accountants and lawyers of the world happy
to make DNSSEC successful.
 
-Rick



-----Original Message-----
From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org]
On Behalf Of Paul Hoffman
Sent: Friday, October 03, 2014 5:44 PM
To: ksk-rollover at icann.org
Subject: [ksk-change] FIPS-140 levels

On Oct 2, 2014, at 10:42 AM, Bolivar, Al <abolivar at verisign.com> wrote:

> I would like to add that I support the addition of another vendor.
> Tomofumi and I spoke to another vendor about introducing a competing FIPS
> 140-2 level 4 HSM. In my opinion having other choices will be positive.

As I understand it, the requirement for the FIPS 140-2 level 4 certification
for HSMs in the current setup came from the US government. Under the
assumption that the US government will not be putting requirements on future
changes to the DNSSEC root keying, this is a good time to look at what the
community wants.

The current setup has the HSM wrapped in a tamper-evident bag, in a safe,
between uses, and that the uses are all viewed by lots of people and
recorded on cameras. Given that, I see no advantages to FIPS-140 levels
above 1. By using these processes, the DNS root key community has our own
tamper evidence, our own tamper resistance, and our own access control
mechanisms.

There are serious disadvantages to requiring level 4 (or even level 2 or 3)
for HSMs: there are fewer vendors, and fewer models from vendors. This is
going to bite us hard if we decide to start using signature algorithms other
than RSA, such as elliptic curves (which are tremendously safer to use than
RSA for the levels of assurance we want for the DNS root).

Even if there are vendors who have FIPS-140 level 4 HSMs for ECDSA using
P256, the IETF is probably going to standardize different curve forms with
different parameters in the next six months. These will come out of the TLS
WG first, but the signature algorithms will probably be everywhere within a
year. There will be lots of publicity for the advantages of these curves
over RSA and over P256. If the DNSSEC root stays with less-safe RSA, or
switches to EC P256 which has already been shown to have operational
problems, because of the requirement to wait for FIPS-140 level 4 HSMs, we
could lose a fair amount of the credibility that we have garnered so far.

If folks here can show that FIPS-140 level 2, 3, or 4 are valuable *in our
already-existing usage environment* (our own tamper evidence, our own tamper
resistance, our own administration controls), I'm all ears. If no one can,
we should start talking about FIPS-140 level 1 or better for future HSMs as
a way to give us more choices of vendors, models, and particularly signing
algorithms.

--Paul Hoffman
_______________________________________________
ksk-rollover mailing list
ksk-rollover at icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141005/f30c9a36/smime.p7s>