[bind10-dev] [sprint planning] estimate result discussion for sprint ending 2013-03-19
Francis Dupont
fdupont at isc.org
Tue Mar 5 16:18:44 UTC 2013
> Using Botan in BIND 10 has the benefit of reducing a security software
> monoculture. A lot of other security related software builds on OpenSSL,
> including BIND 9. If there would be a serious bug discovered in OpenSSL,
> it would have a major effect.
>
> I like the choice of Botan in BIND 10 for this reason.
=> it is not the only reason: Botan is written in C++ in a better
style than OpenSSL too.
> But BIND 10 should only require one crypto library.
=> yes, and BIND 10 should cover all use cases too.
> If I understand correctly, Francis Dupont proposed a plug-able PKCS#11
=> if we want to support crypto hardware (aka HSM) we need to support
the PKCS#11 API. To plug PKCS#11 behind a crypto library can be
feasible: it is what was done for BIND 9 so I can really really
recommend to *not* do that. So the idea is to use directly the
PKCS#11 interface and to plug it to a real HSM or to a piece
of software which implements the PKCS#11 service side.
There are such software HSMs, for instance the Solaris soft token,
openCryptoki and OpenDNSSEC SoftHSM's, including SoftHSMv2 which
can use for backend (i.e., the place where the real crypto is done)
either Botan or OpenSSL (in addition to be clearly DNSSEC oriented).
> interface where the actual crypto "engine" (Botan, OpenSSL, HSM) can be
> changed. That would be a very flexible solution if that can be done in a
> way that is not too complex (as complexity hurts security).
=> in fact there are two questions:
- do we want to support HSMs?
- for a validating resolver, to add a PKCS#11 layer between BIND 10
and the crypto library (Botan or OpenSSL at the choice of the user)
is a critical problem?
If both answers are yes we are in trouble, in all other cases we have
a solution.
Regards
Francis Dupont <fdupont at isc.org>
More information about the bind10-dev
mailing list