On 13 January 2017 at 18:27, Cory Benfield <cory@lukasa.co.uk> wrote:
On 13 Jan 2017, at 08:04, Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia