Re: [Security-sig] Unified TLS API for Python: Round 2
On 20 Jan 2017, at 04:38, Wes Turner <wes.turner@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
On Friday, January 20, 2017, Cory Benfield <cory@lukasa.co.uk> wrote:
On 20 Jan 2017, at 04:38, Wes Turner <wes.turner@gmail.com <javascript:_e(%7B%7D,'cvml','wes.turner@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
On 20 Jan 2017, at 16:30, Wes Turner <wes.turner@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
Got it. Thanks again! On Friday, January 20, 2017, Cory Benfield <cory@lukasa.co.uk> wrote:
On 20 Jan 2017, at 16:30, Wes Turner <wes.turner@gmail.com <javascript:_e(%7B%7D,'cvml','wes.turner@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
participants (2)
-
Cory Benfield -
Wes Turner