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

[Wes Turner]

On Sunday, January 22, 2017, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> > On 21 Jan 2017, at 13:07, Nick Coghlan <ncoghlan at 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 at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/security-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170122/b34e10df/attachment-0001.html>