[Security-sig] Unified TLS API for Python: Round 2

[Cory Benfield]

> On 21 Jan 2017, at 13:07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 
> I agree with Wes that the backwards compatibility guarantees around
> adding new configuration fields should be clarified.
> 
> I think it will suffice to say that "new fields are only appended,
> existing fields are never removed, renamed, or reordered". That means
> that:
> 
> - tuple unpacking will be forward compatible as long as you use *args at the end
> - numeric lookup will be forward compatible

Good idea.

> This intro section talks about a combined "Context" objection, but the
> implementation has been split into ServerContext and ClientContext.
> 
> That split could also use some explanation in the background section of the PEP.

Good idea, I’ll expand on that.

>> Proposed Interface
>> ^^^^^^^^^^^^^^^^^^
>> 
>> The proposed interface for the new module is influenced by the combined set of
>> limitations of the above implementations. Specifically, as every implementation
>> *except* OpenSSL requires that each individual cipher be provided, there is no
>> option but to provide that lowest-common denominator approach.
> 
> The second sentence here doesn't match the description of SChannel
> cipher configuration, so I'm not clear on how the proposed interface
> would map to an SChannel backend.

Yeah, this is a point I’m struggling with internally.

SChannel’s API is frustratingly limited. The way I see it there are two options:

1. Allow the possibility that SChannel may allow ciphers that others do not given the same cipher configuration. This is not a good solution, frankly, because the situation in which this will happen is predominantly that SChannel will allow modes or key/hash sizes that the other implementations would forbid, given the same cipher configuration.
2. Force all other implementations to be as bad as SChannel: that is, to make it impossible to restrict key sizes and cipher modes on all implementations because SChannel can’t.

I don’t really like either of those choices. I *think* 2 is worse than 1, but I’m not sure about that. People with opinions should really weigh in on it.

> This is the one part of the PEP that I think may need to discuss
> transition strategies for libraries and frameworks that currently let
> ssl module exceptions escape to their users: how do they do that in a
> way that's transparent to API consumers that currently capture the ssl
> module exceptions?

The short answer is that users who currently capture the ssl module exceptions need to start catching these exceptions instead when they transition.

Cory