[Security-sig] Unified TLS API for Python: Round 2

[Wes Turner]

On Sunday, January 22, 2017, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> On 22 Jan 2017, at 17:01, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
> - OpenSSL 1.1.0 supports DANE
> - GnuTLS supports DANE
> - AFAIU, neither SChannel nor Secure Transport yet support DANE
>
> So, in order to support e.g. DANE, where would the additional
> backend-specific configuration occur?
>
>
> This would be up to the individual specific backends. They are allowed to
> extend the API provided here in whatever manner they see fit.
>
> A frozen ordered dict would be preferable because:
>
> - Inevitable eventuality of new/additional config parameters
> - Consistency and readability of API access with [], .__getitem__(), .get()
> - https://www.python.org/dev/peps/pep-0416/#rejection-notice ...
> - https://docs.python.org/3.5/library/types.html#types.MappingProxyType
>
> NamedTuple is preferable because:
>
> - Immutability
> - Speed
> - RAM
>
>
> So immutable types are key, and a truly-frozen ordered dict would be fine
> from that perspective.
>
> However, the key reason I want to use a namedtuple instead of a dict is to
> discourage ad-hoc extension of the configuration type (with the side
> benefit of reducing the risk of typo-based configuration and implementation
> errors. Essentially, the dictionary approach encourages adding ad-hoc keys
> into the configuration, which *reduces* auditability and encourages the
> proliferation of essentially implementation-specific keys.
>

So then there are two ways to preserve the centralized configuration (with
a configuration object):

1. extra_config, a TLSConfiguration parameter pointing to e.g. a (mutable)
List or an OrderedDict of additional parameters
2. create an additional configuration object for additional configuration
parameters

KeyErrors and AttributeErrors are indeed useful for catching configuration
errors (in additional to the policy validation opportunity that a
configuration object provides)


> If defined, backed specific configuration settings could take precedence
> over platform-neutral defaults.
>
>
> So, that’s definitionally true. What’s very hard is coming up with a
> general way to express those backend-specific configuration settings, which
> is why I’m not really trying. In fact, it would probably be possible to
> argue that doing that is impossible.
>

An Ordered of these backend-specific configuration parameters - while maybe
not standardizable - could be helpful: cfg.backend_settings[BACKEND_ENUM] =
Ordered the()

One use case is applications which don't/won't define any actual config
code for their app; they just want it to work everywhere (which may mean
working with each platform's native TLS library). There's then an external
config to be read into TLSConfiguration (and whatever else for
backend-specific configuration parameters)


>
> Cory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170122/a1b58a7a/attachment.html>