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

[Ethan Furman]

On 01/22/2017 04:18 AM, Cory Benfield wrote:
> On 21 Jan 2017, at 13:07, Nick Coghlan wrote:

>>> 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.

I am mostly woefully ignorant of these things, but I think option 1 is far
preferable to option 2 -- especially if we get to choose which back-end will
be used.  Even if we can't, I don't think crippling the good actors is the
way forward.

As long as SChannel does not allow / ignores restrictions can we not issue
a warning (probably with the logging module) saying such?

--
~Ethan~