[Security-sig] Unified TLS API for Python

[Nathaniel Smith]

On Fri, Jan 13, 2017 at 12:27 AM, 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.
>
> 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