[Security-sig] Unified TLS API for Python

[Nick Coghlan]

On 13 January 2017 at 18:27, Cory Benfield <cory at lukasa.co.uk> wrote:
>
>> On 13 Jan 2017, at 08:04, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> I'd still be inclined to keep that concern separate from those of the
>> core TLS context (which is about applying a given security context to
>> sockets and buffers) though, and instead have the specific concept of
>> a TLSPolicy that can be used to create TLS contexts that meet certain
>> criteria:
>
> … snip ...
>
>> The standard library could then provide a concrete implementation and
>> default policy that was sufficient to enforce minimum TLS versions and
>> the acceptable cipher suites, while still leaving room for more
>> capable third party policy enforcement.
>
> So, I’d like to rein this discussion in a bit here.
>
> The idea of being able to validate the security and correctness of a collection of TLS settings is a valuable idea. It is also vastly beyond the scope of the problem I’m trying to solve here. I want to very strongly resist the desire that a lot of the community will have to attach additional complexity and responsibility to this module. While it’s very understandable to want to do that (after all, we don’t revisit our standard library TLS functionality often), it will have the effect of chaining a concrete block to this PEP’s ankle and then throwing it into the water.

Note that I'd be reasonably happy to have my post interpreted as "We
can leave policy definition and management until later without really
hindering our ability to add it whenever we want to" - the only
potential change to TLSContext would be to accept an optional "policy"
parameter when creating instances, and that's relatively easy to add
to implementations in a backwards compatible way (the only slight
awkwardness lies in deciding whether or not to pass it along to base
classes during initialization).

However, I'm also aware that one of the awkwards points in the current
SSL module is the significant difference in behaviour between calling
ssl.create_default_context() (good defaults) and instantiating
ssl.SSLContext directly (bad defaults). These are two different
SSL/TLS security policies represented as distinct SSLContext
factories.

For the new module, that can be changed such that tls.TLSContext has
inherently reasonable defaults and a priori notice that the defaults
may change in maintenance releases, so we only have a single
TLSContext factory and a single default TLS configutation policy.

Unfortunately, that would still leave us with the question of how an
API user can compare their own default settings to the standard
library ones (e.g. to emit a warning or error when testing, even if
they've opted out of relying directly on the defaults at runtime).

If I'm understanding Wes correctly, this is the gist of the problem
he's worried about as well - it doesn't do any of us or the overall
ecosystem any good if incrementally evolving the default settings in
the standard library leads to a significant number of developers
instead defining their own "snapshot in time" TLS settings and then
never updating them.

By contrast, if the "default TLS policy" is pulled out as a distinct
object that the tls.TLSContext constructor *uses* to configure the
instance, then it lets us say "If you don't want to rely on the
default settings at runtime, at least validate your own defaults
against the standard library's TLS policy as part of your test suite".

So overall, I think separating out "the standard library's default TLS
settings" as an importable and introspectable object may actually make
the overall design simpler and easier to explain. It just doesn't look
that way right now because the initial draft glosses over the question
of how to define and manage the default security policy (which is an
entirely reasonable approach to have taken!).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia