The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended.

One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.

Security Releases

First, a short item. We are changing our release schedule so that unless there are extenuating circumstances, security releases will go out on a Tuesday, with the pre-notification being the previous Tuesday. We don’t see a need to have people ready to sacrifice their weekend every time a new CVE comes out (see our security policy for details).

On the other hand, a severe enough vulnerability that has known exploits would be a good example of an extenuating circumstance.

Online communication

We created a new mailing list, openssl-project, that is for discussions about the governance and policies of OpenSSL. Anyone can join this list. Only members of the OMC and committers will be able to post.
We want this to be a useful list for the OMC and committers to communicate in public – like many Parliaments, for example, where debate is public but the public doesn’t speak.

Still, not everyone is completely comfortable with this change. It’s an experiment, and we will see how it goes and adjust if necessary. Note that OMC vote results will be posted here, as will initial discussions about vote topics. One important item that will be discussed on this list is planning for upcoming releases. Also, our paid fellows will be posting monthly status reports there.

We decided to increase our use of GitHub. In addition to asking that all bug reports and enhancement requests be reported as issues, we now want all major code proposals to be discussed as issues before a large pull request shows up. This will let the community discuss the feature, offer input on design and such, before having code to look at. We hope this will let us all first look at the bigger picture, before getting bogged down in the weeds of line-by-line code reviews.

We are going to close the openssl-dev mailing list. The distinction between openssl-dev and openssl-users was often unclear, and the changes described above will make that situation worse. GitHub issues are the way most projects work these days, and with the creation of openssl-project it should be much more clear how and when to use the openssl-users mailing list.

If our expectations are wrong, of course, we’ll fix or revert these changes.

Technical Debt

We want to reduce our technical debt. This includes not only things like old open RT tickets or GitHub issues, but also things like refactoring code to make it cleaner and hopefully have fewer bugs. The recent addition of the PACKET and WPACKET API’s in the libssl make the code much more clear, and also avoid hand-coded packet processing bugs (like forgetting to check a buffer against its declared length).

We are getting better on the documentation, but we still have many API’s that aren’t documented. If you want to help fix that, pass the -u flag to the the util/find-doc-nits script.

We have added a new label, technical-debt, to mark these kinds of things on GitHub.

Cryptography Policies

We also came to some decisions about a policy for cryptography, although the wording is still under discussion. The following applies to all new cryptography, and in a future release we will address the existing source.

• Insecure configuration options will not be enabled by default but must be enabled by a compile-time switch. We had already started to do this by disabling SSLv2 and small keys. A recent change is that “multi-prime RSA” will enforce a maximum number of prime factors by default. In the future, it’s possible we’ll increase the minimum key sizes for a variety of algorithms.

• It must be possible to disable all new algorithms at compile-time. When we extend the existing code, we’ll probably skip cases that are known to not work. Building OpenSSL without SHA will break libssl, so it’s not worth spending time on that.

• The EVP interface is the primary interface for calling crypto operations. All new algorithms should only provide this API. In a future release, existing API’s like AES_encrypt will be provided with a compatibility layer, perhaps separately, that wraps the EVP API.

• All algorithms and protocols should be recognized by a national or international standards body. That is somewhat vague, but the important point is that we most of us are implementors, not cryptographers, and will defer judgement to experts.

• The DEFAULT value for the cipher string is not the same as ALL. That is, while many ciphers will be available to the libraries, they will not be enabled at the TLS layer unless specified at run-time. This brought up the point that the syntax of the cipher string cannot support the things people need it to do, including “cipher classes,” custom keywords, and site-wide configurations.

Roadmap

We remain committed to having TLS 1.3 be the main feature for our next release. Of course we must wait for the IETF to finish it. We’ll again point out that this is version 1.1.1, and you should get your applications ready by porting to 1.1.0 now.

We reviewed the status of our license-change work. We’ll post an update in a couple of weeks, but our goal is to change the license with our next release.

We also decided that the primary focus of the next feature release after 1.1.1 will be FIPS. We know that FIPS is very important to some, not all, members of our community and we are committed to addressing this. We don’t have much more information to share, and we know there has been some confusion and misleading communication out there. But we do want to make this strong, definitive statement: OpenSSL will implement a FIPS solution, and we expect it will be completed much sooner than previous timetables indicated.