On Sunday, January 22, 2017, Cory Benfield <c...@lukasa.co.uk> wrote:
> > > On 21 Jan 2017, at 13:07, Nick Coghlan <ncogh...@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 >
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
