> On 13 Jan 2017, at 08:04, Nick Coghlan <ncogh...@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). Cory _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
