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

[Wes Turner]

Got it. Thanks again!

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

>
> On 20 Jan 2017, at 16:30, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','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/16b4e5bd/attachment.html>