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~