Write up an explanation of the rationale behind the legacy provider

[hlandau]

Blocks #436

[hlandau]

@levitte will recount the history of this decision to me and I will do the writeup.

[levitte]

Why the legacy provider?

The legacy provider came into being in early 2019, while we were busy porting diverse old EVP_CIPHER and EVP_DIGEST implementations to providers.

The triggering algorithm was MD2, which was already considered weak, old, and discontinued for any use. We did discuss simply dropping such algorithms entirely, but figured that it was better to be a little bit cautious, in case some old application still uses it.

To still make it possible to separate algorithms that we considered legacy enough to have reasonably fallen out of use, we created the legacy provider, and decided that to be used, it must be loaded explicitly.

openssl/openssl#8541 is the PR where this was started.

The selection mechanism for each algorithm that was placed in the legacy provider was a judgement call, each time. We based the decisions on what the TLS cipher suites required, at least for the TLS versions that are enabled by default. Among others, this lead to the decision to place DES in the legacy provider, but keep 3DES in the default provider.

[levitte]

@mattcaswell, do you agree with my recollection?

[mattcaswell]

Actually, I think we can go back a bit earlier than that PR. I find mention of the legacy provider here for example (January 2019):

https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html

That document actually has a history which goes back even before its publication in January 2019 (I found a draft version mentioning the legacy provider from November 2018). The "pink nirvana" diagrams that that document contained were first developed in August 2018 at this meeting:

https://www.openssl.org/blog/blog/2018/09/25/fips/

It was during that meeting that the legacy provider was first conceived. I don't think MD2 particularly triggered it. The November 2018 draft document I have already has the sentence which is still present in the website version about DES, MDC2, MD2, Blowfish and CAST being moved to the legacy provider. The document doesn't give any rationale for the legacy provider beyond this:

"Legacy provider module(s) will provide cryptographic implementations for older algorithms (e.g., DES, MDC2, MD2, Blowfish, CAST). The OMC will publish a policy for how and when algorithms are transitioned from the default provider to the legacy provider."

My recollection of the meeting was that the intent was to separate out algorithms that are less secure, or no longer widely used which we should discourage new applications from using. Instead we would separate them out into a different provider that could be optionally loaded if access to them was required.

[levitte]

Oh wow, I had completely forgotten the chronology. Thanks for filling in, @mattcaswell!

[mattcaswell]

Actually I looked at the version history for my draft document and found that it was first created on 11th September 2018 and it already contained a diagram with the legacy provider on it (which I think confirms my recollection of it being conceived in the August 2018 meeting)

[t8m]

But in general "the algorithm is assumed to be no longer widely used" was one of the criteria apparently. Not just its insecurity, otherwise at least MD5 which is totally insecure to collision attacks would have to be placed in the legacy provider, but it is used in TLS-1.0 at least and there are other common uses of it.

[t-j-h]

The concept of having a "legacy provider" was raised explicitly in the August 2018 meeting.

It was in the proposed "ToBeArchitecture.pdf" document presented during the meeting. That is when the "pink nirvana" diagram was created which contained the concepts that had been discussed and then presented in the meeting.

I have a copy of the email and the document from 29th Aug 2018 where Matt circulated the draft slides to Richard and myself in preparation for the next days meeting.

Before there were words written down there was the diagram.

ToBeArchitecture.pdf

[t-j-h]

@nhorman where did this writeup end up going? I don't see a reference to how this was resolved (i.e. why it is closed).

[nhorman]

You'll find the rational written from @levitte and @mattcaswell in comments 1 and 3 of this issue. We came to a consensus on the last planning meeting that that writeup was sufficient to address this issue, with the remaining work to write a migration policy being tracked in #436 in the project repository

[t-j-h]

That writeup isn't clear in terms of the final details for anyone else reading it and it is something that belongs in the documentation - i.e. the purpose and rationale behind there being a legacy provider. We shouldn't expect users to have to go hunting for a github issue to find out why we have something the way we have it - and Hugo did volunteer to do a writeup once the historical details were provided (which Richard, Matt and then myself did).