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

[Cory Benfield]

> On 20 Jan 2017, at 16:30, Wes Turner <wes.turner at gmail.com> wrote:
> 
> I think there's somewhat high likelihood that additional parameters will be relevant to TLS Configuration in the future.

I think that we can upgrade “somewhat high likelihood” to “mathematical certainty”. This again fits with my overall position, which is not to pitch this as the completed solution but instead as a good starting point for conservative evolution.

> As to the reduced set of cipher suites, all either do or will have IANA assigned names, and so can be managed as per the cipher enum.
> 
> As to adding TLSConfiguration parameter fields, I think they are subject to the regular standard library update process. Generally speaking we should have a policy that adding fields should be a difficult thing to do unless there is substantial need for their addition, to avoid making the object almost impossible to manage. 
> 
> So the interface contract of the TLS configuration namedtuple is that there are, minimally:
> 
> - .attributes for each of tls._configuration_fields
> - .update()
> - __new__() # instantiation-time validation

Correct. Note that this isn’t an ABC like many of the other classes, but a concrete implementation: it is not generally expected that TLS implementations will want to add behaviours to this object, or to extend it directly.

> IIUC, in order to validate a given configuration, the option is to:
> 
> - subclass TLSConfiguration, define __new__(), and call super()

That shouldn’t be needed: just write a function that accepts one and look at the values.

> So the normal standard library practice of duck-typing (and not explicitly checking for TLSConfiguration in cls.__bases__) does or does not exclude the use of an alternate configuration object which satisfies the interface contract?

Does not exclude a duck-typed object.

> Is immutability a hard requirement of alternate/future implementations?

It’s hard to make immutability a hard requirement because there is no enforcement mechanism for it. However, I think the appropriate caveat is that if some future or alternate config object is mutable, and someone mutates it after passing it to a Context, the outcome of that change is undefined by this abstract API.

Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170120/2f82b182/attachment-0001.html>