Another Face to Face: Email Changes and Crypto Policy

Posted by The OpenSSL Management Committee
,
Jan18th, 20181:00 am

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.