Pre-PEP discussion: revival of PEP 543 - A Unified TLS API for Python

[jvdprng (Joop van de Pol)]

Hi Julien,

Apologies for the late reply! Let me try to answer as many of your questions as possible.

In general, we created this PEP based on the earlier work of PEP 543 and various discussions including this discourse post. We tried to focus on secure-by-default and keeping the API small and simple.

As discussed upthread, we released a version for people to try things out and provide feedback, so your feedback is exactly what we were looking for! I will give some of my own opinions below. However, I hope that we can get some discussion going on the following proposed changes to get a better view of what people think.

@Julien00859

I don’t understand why it returns a non-blocking socket. Is it part of the spec? Is it for async? Aren’t async libraries gonna use TLSBuffer? What should people in a sync environment do? Is setting the socket blocking ok? Should we instead implement our own logic on top of TLSBuffer?

In the original proposal we only had the non-blocking socket without the TLSBuffer, with the reason that we wanted to enable sans-io abstractions. Now that we have TLSBuffer for sans-io abstractions, we could allow the user to choose blocking / non-blocking sockets. However, I am not sure whether this is easily supportable for backends on different platforms.

@Julien00859

Why? I mean I understand why it should be Sequence[SigningChain] server-side, but why is it a single SigningChain client-side?

Our expectation was that the client typically has one client certificate that it wants to present to the server, but this may be incorrect. If necessary, we could set this to multiple certificates, as long as there’s a straightforward way for the backends to handle it.

@Julien00859

There something else I don’t understand, why all the Nones? I get it that a user might not want to decide what ciphers to instantiate the configuration with, to let the system decides on a sane default value, but why can the property returns None as well?

We chose to use None as the default value, so the properties returning None just indicates that they are the default values. Otherwise, each backend has to set their own default values in the configuration when a user creates one with None. Currently, backends can implement their own checks in validate_config, but I can see the value of certain sanity checks regarding lowest_supported_version <= highest_supported_version. Whether the private key and certificate match seems like a more backend-dependent check to me, especially if the backend wants to reference these items by identifier.

@Julien00859

Unless we want to support TLS 1.2 unsafe ciphers DH_anon_*, the ServerCertificate.certificate_chain must be set and non-empty (it’s a requirement of TLS), it should be a mandatory parameter server-side.

This makes sense to me. We can allow empty server certificates in the insecure module.

@Julien00859

The same goes for ClientCertificate.truststore, it is set None by default at the moment, making the connection insecure by default. It should be a mandatory parameter client-side. Users who wish for an insecure connection are free to explicitly set the param None.

The backends are supposed to interpret a None trust store as the default (system) trust store. I am not sure if it would really make the connection insecure by default, as a missing trust store means all servers should be rejected. In order to skip the server certificate check, the user has to use the insecure module.

@Julien00859

At the moment the only cryptographic primitives that are configurable with tlslib are the cipher suites (AES). I don’t know for TLS 1.2, but in TLS 1.3 the key exchanges (DH/x25519) and signature schemes (RSA/ECDSA) are negotiated as well. TLS 1.3 can even use a configuration to select the peer’s public key, and another to select the peer’s certificate chain (not implemented in siotls yet).

Yeah, currently the cipher suites for TLS 1.3 only focus on the symmetric ciphers and doesn’t include supported groups, signature algorithms, or PSK. I would appreciate more input from users whether additional negotiation needs to be supported. With regards to your followup post, I would really like to avoid complicated ways to define cryptography/cipher suites as the different backends are already complicated (especially OpenSSL and Schannel).

@Julien00859

Like the configuration, I’ve got more negotiated stuff than tlslib, hence the dedicated object. I have no strong opinion but I fear there’s gonna be lots of negotiated_... attributes, just wanna open the discussion on what you think seems best?

I like the idea of having a dedicated object for this.

@Julien00859

For this to work with tlslib, I would need a PublicKey class pretty much like the existing PrivateKey one. There should also be an entry for a Collection[PublicKey] in the config, or could it be something in TrustStore? Same goes for SigningChain.

Anyway, I would like to open the discussion on this matter as well.

I’m generally not a big fan of adding additional things to the API because it detracts from the simplicity. However, if that’s what users need, I’m open to it.

@Julien00859

As a user, should I open and parse those files myself? Using Certificate.from_buffer for every PEM-certificate I find in the files? Or can I use Certificate.from_file directly?

Same goes for the other side, in siotls, should I expect a Certificate.buffer to hold multiple concatenated PEM certificates?

That’s a good question, I need to think more about it. I’m fine with the end user dumping in certificates as is most convenient for them and the backend handling everything.

@Julien00859

I’ve been trying to think of a solution, but it is getting late (2AM). All I can say is that I’m pretty confident the current close() will prove problematic.

As I understand it, the current close() allows you to close the read side via flag, which is allowed as per the paragraph that you cite, but opens you up to truncation. However, I also didn’t really like what we ended up with here, so if there are any better suggestions I’m all ears!

@Julien00859

I’ve got a question, would a forking server works?

We didn’t really think about this when writing the PEP and I don’t have a quick answer here. If you have any proposed modification I’m happy to take a look. I suppose it will tie into the close() discussion above.

@Julien00859

Still, this is my first time contributing to a pep, so if anybody could leave a (short) message telling me it is not worthless I would be grateful .

After our initial release we did not receive any feedback until yours. As a result I am not sure how much interest there currently is in this PEP. Therefore, I would also appreciate any input from others on their opinion (which will probably have changed since the last time we discussed this PEP!).