On Sunday, January 22, 2017, Cory Benfield <cory@lukasa.co.uk> wrote:
On 21 Jan 2017, at 13:07, Nick Coghlan <ncoghlan@gmail.com <javascript:;>> 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.
Looking at the GnuTLS manual [1], I see a number of potential additional configuration parameters: - session resumption (bool, expiration time) - Trust on first use (SSH-like) - DANE [2] - [1] https://gnutls.org/manual/gnutls.html#Selecting-cryptographic-key-sizes [2] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ... IDK about *args (and integer namedtuple field indexing). I also (these days) tend to disagree with items-accessible-as-attributes dicts because dashes and consistency of API.
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.
GCD, LCD. 3. ciphers__.get(SCHANNEL) OR ciphers
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.
Are these exceptions redundant? Could they derive from the new TLSError as well as the existing comparable exception?
Cory
_______________________________________________ Security-SIG mailing list Security-SIG@python.org <javascript:;> https://mail.python.org/mailman/listinfo/security-sig