On Friday, January 20, 2017, Cory Benfield <c...@lukasa.co.uk> wrote:
> > On 20 Jan 2017, at 04:38, Wes Turner <wes.tur...@gmail.com > <javascript:_e(%7B%7D,'cvml','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/ > > - 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 >
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
