On Fri, Jan 13, 2017 at 12:09 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 13 January 2017 at 07:05, Wes Turner <wes.turner@gmail.com> wrote:
> +1 for start simple and iterate;
> but expecting a config object is not easy to add later.

Yes, it is - all that is necessary is to add a "make_ssl_context"
helper function that translates from the declarative configuration
format (however defined) to the programmatic API and returns a
configured context of the requested type.

The appropriate time to define that lowest-common-denominator
configuration format is *after* there is a working programmatic API
that covers at least the 3 major implementations of interest (OpenSSL,
SecureTransport, SChannel), and hopefully a few other implementations
as well (e.g. NSS, BoringSSL).

So, rather than scattered throughout each implementation,

I think it would be wise to provide guidance regarding configuration validation.

Enumerating the parameters into a common schema certainly will require actual implementations to define a superset of common dict keys; which I believe would be easier with a standard SSLConfig object.

Another reason I believe there should be a configuration object with a .validate() method for centralized SSL configuration:

- Having one .validate() method (with as many necessary subvalidators) provides a hook for security-conscious organizations to do SSL/TLS configuration validation in one place. (Otherwise, this type of configuration-validation must be frequently-re-implemented in an ad-hoc way; which inopportunely admits errors)

- Examples of SSL/TLS configuration validation criteria:

- https://en.wikipedia.org/wiki/FIPS_140-2#Cryptographic_Module_Validation_Program

- https://mozilla.github.io/server-side-tls/ssl-config-generator/

- "CIS Critical Security Controls" https://www.cisecurity.org/critical-controls.cfm

- CSC 3.[*]

- Least-privilege dictates that this type of config is separate from the code.py files

- "CWE-327: Use of a Broken or Risky Cryptographic Algorithm" (2011 Top 25 #19)

https://cwe.mitre.org/top25/#CWE-327

https://cwe.mitre.org/data/definitions/327.html

- ... "improper configuration" is basically this issue; so, validation should be encouraged where possible.

Again, I think we should encourage validation of SSL/TLS configuration settings;

and pointing to SSLConfig.validate() as the method to subclass makes that very easy.