Include support for Post-Quantum Cryptography as experimental #279
Comments
|
I am thrilled with the recent activity and input. Thank you. Yes, we should consider how to include this in the guidelines. I personally prefer 'future' or 'next' over 'experimental'. I'll keep this in mind for #270, too. For server software for which we emit configuration for TLSv1.3 groups (none currently), we might (for now in #270) include the PQC groups in a comment until the guidelines are updated. Related, I could use some help getting the https://github.com/mozilla/server-side-tls guidelines updated with input from those inside Mozilla security. Do you have any contacts or recommendations how to best approach this? At the moment, other privileged contributors to this repository are mired in what I consider wasted effort trying to output 'safe' configurations for the guidelines last updated (substantially) in 2020, and for which I think we would do better by omitting DHE ciphers from the recommendations and by avoiding providing recommendations for end-of-lifed software. I think it would be better to loudly warn ssl-config-generator visitors if the software versions they input are outdated and end-of-life, no longer receiving maintenance from upstream developers, and I submitted PR #281 as an initial stab at doing so. |
the issue is that those IDs are not assigned to RFCs but rather to Internet-Drafts; technically they are not final, that's the only reason why I think they should be marked as experimental
as far as I know, all the people responsible for that are also in this project...
just because a particular software version is abandoned by upstream, doesn't mean that there are no people actively maintaining it (SuSE, Debian, Ubuntu, RedHat, to name a few, are in the business of doing exactly that), but this is offtopic for this issue |
|
In #284, I am proposing to explicitly define a list of Groups/Curves in the configs of servers that support it in the config. The reason is due to OpenSSL 3.0 adding ffdhe* groups to the defaults, potentially exposing servers supporting TLSv1.3 and OpenSSL 3.0 to DHEater attacks. (See #162) There may be some challenges to communicate how to extend and enable this in the configs for PQC groups. For example, X25519Kyber768 is not exposed in Go 1.23, but if CurvePreferences is nil (in Go code), that PQC group is enabled, along with all the others. See caddyserver/caddy#6540 Not defining
From personal experience, I have seen EOL software maintenance to be more often reactionary, instead of proactive. I do not doubt that others may be proactive and be reviewing every upstream commit for backport, but even that is prone to mistakes and misunderstandings about what is more important or less important for security. Then, there is the situation where upstream has made code transformations which make cherry-picking and backporting more difficult and prone to integration mistakes, some which might turn into security exposures. In any case, I am not privy to the levels of private commercial support, and hope that the private commercial support is providing secure recommendations to private clients for configuring and maintaining older versions of software that are no longer publicly maintained. My personal opinion is that this public site (ssl-config-generator) should focus on providing recommendations on how to configure TLS for publicly supported and maintained software versions. I think there is a benefit to letting the average visitor to ssl-config-generator know if they have input into the ssl-config-generator an old software version no longer publicly maintained, so that the visitor might consider upgrading their system before spending time configuring it. If you think #281 is taking the wrong approach, or if the wording could be improved, I would be interested in your feedback in #281. Thank you. |
Yes. I think that point might be in the future, when modifying the server application configuration list of Groups/Curves is the only step needed. Right now, the reader must take additional steps to enable PQC groups.
At this time, I do not think the ssl-config-generator should expose this in the generated configs. Instead, we might consider adding documentation about how to enable this experimental support, e.g. which packages to install on common Linux distributions (Fedora/Redhat: Servers which support configuring Groups/Curves now include that configuration directive in ssl-config-generator output, and the name contains "curve" or "group" and X25519 in the value, so documentation could direct the reader to add the PQC group to that line, with spelling provided for server apps using OpenSSL, and for Go-based server apps. OpenSSL 3.2 GnuTLS 3.8.7 (15 Aug 2024) with liboqs supports Go 1.23+ |
working in said corporation providing commercial support, I'm obviously quite biased, but backporting security fixes, and making sure that they don't have unintended consequences is like half of our business model... and given that we clearly have customers, there are quite a few people that trust corporations like that to do good enough of a job that upgrading to bleeding edge may not be so hot when all you do is run accounting... And while yes, we do also provide guidance for customers on how to configure the software we ship, it's only that: guidance. They're free to go to any place and take the configuration from there.
on distro like Fedora, for OpenSSL, doing just a
people that know such details do not need to use this generator in the first place, it's for the intermediate group, where they need to learn that this is an option in the first place |
I agree. I was thinking of adding a section of text below the generated config for each server application. Such a section could contain links to upstream documentation as well as potentially include optional information including hints for setting up PQC such as what I posted previously. |
Firefox ships with support for the X25519MLKEM768 group from draft-kwiatkowski-tls-ecdhe-mlkem-02. Similarly, current versions of openssl (>= 3.2.x) with current versions of oqsprovider (== 0.7.0) support that key exchange on the server side (other browsers and libraries with support for this key exchange are available).
At the very least, I think we should start to think at what point do we start including PQC in the configured groups.
Optimally, we should have a switch, labelled "experimental", to enable post-quantum key exchanges in the existing configs.
The text was updated successfully, but these errors were encountered: