[bind10-dev] BIND10 in FIPS 140-2 environment

[Adam Tkac]

On Tue, Mar 19, 2013 at 03:56:30PM +0000, Francis Dupont wrote:
> > if I understand BIND10 correctly, botan is currently only one
> > supported cryptographic library. Although from developer point of
> > view it's absolutely OK, this decision can have serious consequences
> > for BIND10 in FIPS 140-2 certified environments (like governments or
> > financial/health-care companies) because bo tan is not certified
> > cryptographic library.
> 
> => as the local expert (in fact not expert at all but the only person
> who invested time to understand how to handle this particular question)
> in FIPS 140-2 stuff, what is the real market for this? The question
> is both for BIND9 and BIND10 and is *not* technical (nor your response
> directly for me).
> 
> > May I ask you if there are any plans to port BIND10 to some
> > certified library ?  (openssl/nss/libgcrypt).
> 
> => BTW I didn't know libgcrypt was certified. (*)
> 
> > If no, will you accept contribution of patchset which will add
> > possibility to link BIND10 against openssl, for example?
> 
> => BTW I already did this (OpenSSL based cryptolink) but more as a proof
> of concept than for production. My current proposal is to use PKCS#11
> directly in cryptolink, so it will work with HSMs and with the
> new SoftHSMv2 which supports both Botan and OpenSSL backends.

If BIND10 will use SoftHSMv2 linked against OpenSSL, I think it's absolutely OK
(i.e. SoftHSM will act as PKCS#11 wrapper around openssl).

> 
> > Or you prefer to stay with botan, even if it can disable deployment
> > of BIND10 in FIPS 140-2 environments?
> 
> => there was no decision today (nor an official announce for SoftHSMv2)
> but my proposal should work with FIPS 140-2 level > 1 environments
> (any certified software can be only level 1 by definition).
> If things are the same in USA as they are in France, only the hardware
> can be trusted so direct PKCS#11 support solves both the HSM and
> the FIPS 140-2 questions in the best possible way (:-)!

Yes, direct PKCS#11 calls seems like the best approach for me.

> 
> Thanks
> 
> Francis Dupont <fdupont at isc.org>
> 
> PS: I did the work for bind 9 (OpenSSL certified module, removed MD5
> dependencies, added a hook to go in FIPS mode, etc) but as nobody
> who understood really what is FIPS 140-2 asked for it it never was
> a candidate for becoming a product. In fact I believed the only FIPS
> related detail in current bind 9 code is the -F argument flag is
> reserved in all commands...

In my opinion this is not needed. It's enough to instruct operating system to
run in FIPS mode and all non-FIPS stuff (like uncertified or weak algorithms)
are disabled directly in openssl so every call of the unsupported stuff fails.

> PPS (*): thanks to have certified the libgcrypt for RedHat (even
> I'd prefer it would be certified for itself, i.e, 1747 vs 1758).
> BTW it should fine to get a module with ECDSA certified too
> (in the case you can make something for the next certifications).

-- 
Adam Tkac, Red Hat, Inc.