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

[Cory Benfield]

> On 20 Jan 2017, at 04:38, Wes Turner <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/ <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/ <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.

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. 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/2af229c7/attachment.html>