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

[Wes Turner]

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

>
> On 20 Jan 2017, at 04:38, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
> Thanks! TLSConfiguration looks much easier to review; and should make
> other implementations easier.
>
> I read a great (illustrated) intro to TLS1.3 the other day:
>
> https://temen.io/resources/tls-gets-an-upgrade:-welcome-1.3/
>
> - 1-RTT and 0-RTT look useful.
> - There's a reduced set of cipher suites
>
> https://tlswg.github.io/tls13-spec/ #rfc.section.4.3
>
> - Are there additional parameters relevant to TLS1.3 for the
> TLSConfiguration object?
> - If necessary, how should TLSConfiguration parameter fields be added?
>
>>
> So both 0-RTT and 1-RTT have little to no library support at this time.
> Certainly the three main implementations that this proposal considers
> (OpenSSL, SChannel, SecureTransport) have no public APIs to control this
> kind of functionality. Indeed, none of those implementations is shipping
> TLSv1.3 yet as far as I’m aware. OpenSSL has a date by which they plan to
> have TLSv1.3 support complete, and based on Apple’s adoption of TLS tech
> I’d expect to see TLSv1.3 in SecureTransport within 18 months and possibly
> as soon as September. The TL;DR here is that I think we should not attempt
> to spec APIs for 1-RTT and 0-RTT yet, until we understand how
> implementations plan to support it.
>

I think there's somewhat high likelihood that additional parameters will be
relevant to TLS Configuration in the future.


>
> 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

IIUC, in order to validate a given configuration, the option is to:

- subclass TLSConfiguration, define __new__(), and call super()

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?

Is immutability a hard requirement of alternate/future implementations?


> However, otherwise the regular standard library concerns should all apply.
>
> Cory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170120/65de8f72/attachment.html>