[ksk-change] FIPS-140 levels

[Tomofumi Okubo]

Hi Paul,

When security engineers design a service, one of the things they
consider is "defence in depth".
The idea is establishing layers of security controls so that failure
of one will not be as critical as it would be. (a.k.a. don't put all
your eggs in one basket)

What you suggested is simply lowering the security level for
convenience as you did not suggest compensating controls. Instead you
just suggested removing controls as it is overlapping with existing
ones. Changing the design not as easy as one might think.

I'm all for an idea that improves the design but not the other way around.

IMHO, it is better to have tamper evidence (level2) and tamper
resistance (level3) at the HSM level. I personally think the
environmental controls (level4) might be too much but it is true that
it has controls that protects the cryptographic key from different
type of attacks.

Cheers,
Tomofumi

On Sun, Oct 5, 2014 at 12:30 PM, Richard Lamb <richard.lamb at icann.org> wrote:
> Ooo...Was just trying to be diplomatic .."a bit".  You know that is not my
> usual mode :-)
>
> As long as we can "sell" DNSSEC to the wider audience and the community
> accepts the risks, I am fine.  The engineering was never really so much of a
> problem.
>
> Our auditors have not said anything negative.  Its just if you look at
> standard CPSs and have conversations with various auditors - we spent $$ on
> advice from many - , there is definitely a common framework that all of the
> Webtrust/Systrust audited entities seem to follow, FIPS 140-2 >= level 3
> being one.  I am not arguing for any of this at an engineering level.
>
> I know you are much more expert than I in these things and am happy
> following my true instincts and creating something based on engineering
> logic rather than following the herd*... but my business side says it must
> sell.  And selling isn't always based on sense - otherwise I would be rich.
> Just want to make sure by tossing out FIPS 140-2 level 3+4 we are not
> throwing something useful in promoting DNSSEC to business away.  Its your
> call.
>
> Thanks for the offer to help doc and new practices when we take them on. You
> are obviously already a sought after member of the community.
>
> We do have a couple new guys who's difficult task it is to maintain the 16+
> policy+procedures docs around the root KSK operations that our auditors see.
> They are sharp and I am hoping they get up to speed soon.  Tomofumi, Dalini,
> and I are tired.
>
> -Rick
>
> *FWIW, personally, I built my own hsm, alarm systems, wrote my own (slow)
> RSA+miller rabin, off-line custom s/w signer for my stuff just so I know who
> to blame ;-)  .. Id like to use djb curve25519 - is it any good?
>
>
> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman at vpnc.org]
> Sent: Sunday, October 05, 2014 11:41 AM
> To: Richard Lamb
> Cc: ksk-rollover at icann.org
> Subject: Re: [ksk-change] FIPS-140 levels
>
> On Oct 5, 2014, at 11:28 AM, Richard Lamb <richard.lamb at icann.org> wrote:
>
>> 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.
>
> Note that I didn't say "a bit". FIPS-140 levels are progressively more
> restrictive, and I asked for examples of anything that we even need in level
> 2 that we do not provide ourselves.
>
>> 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.
>
> The banking community is one which understands physical security better than
> most. The kinds of things that IANA does for tamper evidence, tamper
> prevention, and operational role separation are way more effective and
> constantly provable than a FIPS-140 validation. This is particularly true
> because you cannot easily verify that a device is operating in "FIPS-140
> mode". Banks appreciate proof, and the recording of the ceremonies and of
> the physical protections do that.
>
>> 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.
>
> Can you be more specific about the latter? That is, is there an auditor who
> is saying that IANA needs to conform to "common practice", not the better
> practice that you have instituted?
>
>> 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.
>
> It could certainly help to document IANA's current (and expected future)
> practices in the same terms as what NIST uses for FIPS-140
> higher-than-level-1 certification. The folks closest to the process already
> take some of those things for granted, but the communities you care about
> will want to hear about them.
>
> --Paul Hoffman
>
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
>