Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Alternative to BOTAN: OpenSSL (Tomek Mrugalski)
2. Re: Alternative to BOTAN: OpenSSL (Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Apr 2014 12:38:24 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Alternative to BOTAN: OpenSSL
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
------------------------------
Message: 2
Date: Wed, 16 Apr 2014 06:58:16 -0400
From: Thomas Markwalder <[email protected]>
To: Tomek Mrugalski <[email protected]>, [email protected]
Subject: Re: Alternative to BOTAN: OpenSSL
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
> [email protected]
> 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
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 1, Issue 4
*************************************
