Also, if I understand PEP-1 correctly, this forum thread was created in the Ideas section to open the discussion about reviving PEP-531 and lead to the publication of draft PEP-748. Now that the draft exists, shouldn’t this discussion me moved to the PEPs section? I’m asking because it seems that the Ideas forum attracts less views from core-developers than the Peps one, and I think the document is mature/important enough to warrant more eyes.
Yep, starting a new thread in the PEPs section after the PEP is updated would make sense.
As for the PRs, content changes are primarily the concern of the authors while the PEP is still a Draft, so it’s up to you (and William) if you want to be able to link the three categories of changes separately in the commit history rather than having them all combined in a single commit.
It’s more about having three separated PRs where we can discuss each change, than about the final git history. @woodruffw doesn’t seem to be active on this PEP anymore, what should we do?
If there are specific wording details you’d like to discuss, separating the PRs is fine (it’s a trade-off between focusing each review and potentially finding the changes aren’t as distinct as first believed, leading to split discussion of actually related changes).
Whether @woodruffw still wishes to be actively consulted as a co-author or acknowledged as a significant contributor is a question only William can answer.
Sorry, I just haven’t had time to dedicate to this PEP (it’s not tied to my job anymore, unfortunately). I’d like to be helpful but realistically I won’t have a lot of time to dedicate to any reviews for at least the next few months, so it’s probably best to leave me out of any consultations 
2 Likes
Thanks for the PRs, @Julien00859!
I think we need a new topic in the PEPs section for the context change, because it draws in a lot of socket API surface. We can also raise the remaining question of getting rid of cipher suites in the main API and move them to some kind of hazmat layer.
Ok, I’ll open a third PR then 
What is the status of this proposal?
Currently, the PEP is implemented as a separate package, for people to use and provide feedback. So far, the implementation includes only the OpenSSL backend. Although there has been some work on using Microsoft’s SChannel as a backend, the work stalled until people show more interest.
@Julien00859 has added their own TLS library as a backend, has provided some feedback, and has some in-flight PRs against the PEP. I’m a bit behind on providing a second round on feedback on the PRs.
The plan is to get those PRs merged if possible and then open a new topic on the PEP board to discuss bigger changes to the PEP.
3 Likes
Regarding ciphers I spent a couple evenings trying to specify something but I’m not ready at this point to open a PR.
At fosdem we weren’t sure of the direction to take. We discussed about removing the “cipher suite” configuration altogether and to rely default system configurations. We also discussed about adding the missing key-exchange and signature-scheme list of TLS 1.3.
There are a couple RFCs regarding Post-Quantum (either solo, either hybrid with ECC) that are about to be published. There are lots of discussion going on at the IETF regarding solo MLKEM vs hybrid ECC+MLKEM, with the US pushing for solo (via NIST) and the EU preferring hybrids (in a lesser extend; via ENISA). The risk is that some regulation force using one, or the other, and softwares will need to comply (at least to be certified) hence would need to also be able to negotiate key-exchange in addition to cipher-suites.
I’ve experimenting doing a TLS 1.3 → TLS 1.2 cipher suite conversion utility (following one of my old message in this thread). It exists over there, not sure it’ll be of any use. The tls13.csv file in the root folder showcases the utility.
All in all, I’m unsure of the direction to take. I’m still favoring just doing it the TLS 1.3 way with 3 lists (cipher suites, key exchanges, signature schemes) instead of a single one. I’m confident it will be possible to convert those 3 lists in whatever format each TLS backend is using. I understand we want to keep it simple. AFAIC good default values are simple enough.
Julien00859 has added their own TLS library as a backend
To be precise, it still is a PR that is not merged yet. #26 - WIP: tlslib - drlazor8/siotls - Codeberg.org
How is then different from cryptography and why the better approach to this problem would be to add (finally) another backends to it?