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

Cory Benfield cory at lukasa.co.uk
Sun Jan 22 07:18:06 EST 2017


> 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



More information about the Security-SIG mailing list