Getting Samba out of crypto (was: Re: [PATCH] Update to the Samba crypto requirements document)

[Andrew Bartlett]

On Wed, 2018-01-03 at 11:36 +0100, Andreas Schneider via samba-
technical wrote:
> Hi,
> 
> I've had a call with Nikos (GnuTLS maintainer) and we updated the REQUIREMENTS 
> document.
> 
> We've opened bugs to support missing crypto algorithms we require in GnuTLS 
> and nettle. The plan is to move to GnuTLS one day to get out of the crypto 
> business and have more hardware accelerated crypto in Samba.

Picking this part of the thread back up, I would really like to get
Samba out of the crypto game.  Even when copied from a 'safe' source
(and while we trust it, if you were an auditor would you say Heimdal
really the most well-respected source?), each one of these libraries
needs careful checking.

Others feel the same way.  I've been slowly trying to get Samba the
'CII Best Practices' badge:
https://bestpractices.coreinfrastructure.org/projects/200#security

There, one criteria is:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/
doc/criteria.md#crypto_call

> If the software produced by the project is an application or library, 
> and its primary purpose is not to implement cryptography, then it SHOULD
>  only call on software specifically designed to implement cryptographic 
> functions; it SHOULD NOT re-implement its own. (N/A allowed.) [crypto_call]

Similarly, I've been asked to explain our in-tree crypto for a client,
resulting in this page:

https://gitlab.com/catalyst-samba/samba-docs/wikis/cryptography/where-is-the-raw-crypto-implemented

I came back to this because the shamozzle in the encrypted_secrets
module was raised in https://bugzilla.samba.org/show_bug.cgi?id=13276

As background, the choice of dependency there on either nettle or
GnuTLS came about because the project started with GnuTLS, but then it
was discovered later that RHEL6 (an important target platform) didn't
offer the AEAD modes we wanted to use.  

Sadly the in-tree option was missed.  (However while helpful in this
instance the duplicate bindings isn't a pattern I would like to see
repeated often.)

So, I would like to know what the remaining technical/political
barriers to getting out of the crypto game really are:

* Are we willing in principle to require users install a crypto library
like libnettle?   

* Alternately (if anything) are we willing to disable for users who
"can't/won't" install it?  

(I'm very comfortable with the AD DC requiring external crypto libs as
long as it is installable somehow on RHEL 6).

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba