On 03-Jun-18 02:00, Ondřej Surý wrote:
> Hi all,
>
> BIND 9 currently supports two major cryptography provider libraries -
> OpenSSL[1] and PKCS#11.
>
> The PKCS#11 interface is very fragile, as the different vendors implement
> different parts of the
> standard, and BIND needs to be compiled with a specific PKCS#11 provider
> defined at the
> compile time. This is certainly suboptimal, and we are looking at ways how
> to improve that.
>
> So, if you are running BIND with PKCS#11 HSM, or you are thinking about such
> setup,
> I would be interested to hear answer to couple of questions:
>
> 1. What functions of PKCS#11 do you care
> 1a) getting entropy?
> 1b) message digests?
> 1c) HMAC?
> 1d) symmetric crypto (meaning AES)
> 1e) public-key cryptography (aka DNSSEC keys)
>
> (Background: PKCS#11 as currently used in BIND uses PKCS#11 exclusively
> for anything related to crypto.)
>
> 2. Would you be fine if BIND double linked with OpenSSL and PKCS#11?
> (Background: if some of the answers to previous question were NO, BIND would
> have to use OpenSSL as a provider for these functions and it would make
> the code more slimmer, and easier to test.)
>
> 3. Would you care if BIND wouldn’t link directly to PKCS#11 library and used
> OpenSSL engine: https://github.com/OpenSC/libp11#openssl-engines
> (Background: the PKCS#11 is full of #ifdefs, for full picture see [1], and it
> doesn’t really make sense to develop the same work-arounds at two different
> places.)
>
> ~~~
>
> There are three possible course of actions we might take:
>
> 1. Convert the PKCS#11 usage to OpenSSL PKCS#11 engine. That would
> save us from most of the headaches with PKCS#11, but it might require some
> configuration changes for existing deployments.
>
> 2. Convert the non public-key cryptography parts to OpenSSL. This would
> allow people to keep the DNSSEC private keys inside the HSMs, but all
> the other crypto would come from OpenSSL. (OpenSSL itself has FIPS
> 140-2 validation if that means anything to you.)
>
> 3. Keep the status quo
>
> There are some options to these three:
>
> A. Improve the PKCS#11 handling to runtime detection of HSM capabilities
> B. Support OpenSSL and PKCS#11 DNSSEC keys at the same time, say
>to store KSKs in PKCS#11 and ZSK on disk...
>
> The A is non-issue for 1., likely to happen with 2., and unlikely to happen
> with 3.
> The B will happen with 1., likely to happen with 2., and impossible to happen
> with 3.
>
> As usual, the goal is to balance the time we have to spend on improving BIND,
> and our development resources are limited, so any resources saved by reducing
> the code we need to maintain would free our hands to do something else (like
> A or B).
>
> Also please note that this is not going to affect any previously released
> version of BIND,
> just future releases.
>
> 1.
> https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/isc/include/pk11/site.h
> 2. https://www.openssl.org/docs/fips.html#background
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
>
With the caveat that I don't currently use PKCS#11 with BIND:
#1 - use OpenSSL's engine seems the most reasonable. Puts most of the
maintenance burden on them.
Perhaps you can have a script that recommends the necessary
configuration changes - presumably
this is a one-time thing.
It seems to me that the biggest pain for users is having to compile
against a specific provider. This makes life hard for packagers (and end
users who compile bind). If nothing else, it would be useful to (I
guess this is option 4):
a) specify the provider at runtime - e.g. load the right DLL
b) be able to separately compile that (those) dll(s) for whatever
provider, generating a unique name.
This would allow packagers to pre-compile whatever set of
providers their customers want, and
allow specifying which one in the config file. It would be
minimal change to your code - mostly Makefile
magic. Essentially, the BIND version of OpenSSL engines...
Put another way: in configure one does something like
--build-pkcs11=(hsm1, hsm2, hsm3, softhsm, ...)
and you get hsm1.so, hsm2.so, hsm3.so, softhsm.so ... and a BIND
that knows how to load/call whichever
one is loaded, but no provider-dependent code. Then the bind
config file has 'pkcs11-provider "hsm2";'
The BIND code -with whatever ugliness - remains unchanged until,
and unless you decide to refactor it.
That could be incremental - and transparent to users.
In fact, one of the providers could be OpenSSL (or its engines)
under a BIND interface wrapper...
Also, this is a static choice - not "runtime detection of
capabilities". You could do that eventually, of course, as
part of refactoring to consolidate some/all of the libraries.
But the end user just configures one
name for his/her provider. The idea is to keep things simple -
for the user, and for development.
On the other hand,
