On Fri, Jan 13, 2017 at 12:27 AM, 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.
I want us to develop a culture around TLS functionality where we are willing to continually iterate on it, and where the community feels willing-and-able to provide extensions and new functionality incrementally, rather than all at once. Let’s not have the perfect be the enemy of the good here. I highly recommend that people who are interested in TLS policy workshop a separate PEP that discusses what we should build to resolve that issue. But we should not block solving problem A (how do we use something that isn’t OpenSSL with the standard library) on solving problem B (how do we define and enforce TLS policy).
The potentially-useful idea I took from this subthread was: right now we have an interface with a bunch of getter/setter methods. Would it make sense to *replace* that with something more declarative, like a single method that takes configuration data in some sort of standard format? Something very non-clever and simple, like, a dict? That seems like it might both simplify the interface (e.g. the sni callback can return one of these dicts instead of trying to specify OpenSSL's context switcheroo weirdness; if the new dict tries to change options that this particular implementation doesn't allow to be changed, then it's free to error out) and be more flexible (e.g. people could write validation routines that take one of these dicts and raise an error or not -- having a standard format enables this but also makes it not our problem). -n -- Nathaniel J. Smith -- https://vorpus.org