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~
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
