Alternative to BOTAN: OpenSSL

Thomas Markwalder tmark at isc.org
Wed Apr 16 10:58:16 UTC 2014


On 4/16/14, 6:38 AM, Tomek Mrugalski wrote:
> We were told by mutliple sources (specifically, coming from FreeBSD
> community and RedHat) that Kea dependency on Botan is an issue. I heard
> the concerns coming from FreeBSD only second (or third) hand, so I can't
> comment on their accuracy, but the issue was that to ever consider Kea
> (or BIND10 DNS) for a default installation, it would require adding
> extra library to base installation. The problem was not with botan being
> unavailable.
>
> The second objection to Botan was coming from RedHat. Thomas Hozza said
> that RedHat has certification procedures and 3 crypto libraries passed
> defailed security audit: NSS, GNUTLS and OpenSSL. They are unwilling to
> go through the hoops to certify fourth library (botan).
>
> Our plan was to get rid of Botan completely and replace it with OpenSSL,
> as it is available everywhere and universally accepted. However, due to
> recent developments with Heartbleed, people may revisit their
> unconditional belief in OpenSSL. And so should we.
>
> I'd like to propose changing our goal wrt to Botan/OpenSSL a bit.
> Instead of replacing Botan with OpenSSL as crypto provider, we should
> have the capability to use either. Depending on the availability (or
> parameter passed to ./configure) we could use Botan or OpenSSL.
>
> For people who are alergic to Botan, we would recommend OpenSSL. And
> vice versa.
>
> Thoughts? Comments?
>
> Tomek
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
As with our other services, using an interface layer to abstract away
any implementation dependencies is the most viable thing to do.  People
like choices.   With a day or two of proper analysis and design it
should be a relatively simple matter to extend/rework the cryptolib
interface to accommodate this.   Afterall, that was the intent with this
library as far as I can tell.  

As to which ought to be the out-of-the-box default I would suggest it be
whichever of the two is most likely to already be present in a given
environment.  My impression is that would be OpenSSL.  The easier it is
for someone to get up and running with Kea the better.  They will always
refine things as their understanding of the product and as it pertains
to their needs evolve.

As an aside I'm not so sure that OpenSSL will suddenly be perceived as a
evil or vulnerable.  Perhaps on the contrary, since it is so widely used
it is scrutinized that much more intensely and reaction to fixing issues
with it is immediate.   Better the devil you know than the one you don't eh?

Thomas






More information about the kea-dev mailing list