> On 20 Jan 2017, at 04:38, Wes Turner <wes.tur...@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
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
