Do we really want to have the legacy provider as opt-in only?

[Matt Caswell]

On 15/07/2019 14:43, Tomas Mraz wrote:
> On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
>>
>> On 15/07/2019 13:58, Tomas Mraz wrote:
>>> Hi everyone,
>>>
>>> if the Subject was already fully discussed and thought through then
>>> please disregard this but otherwise I'd like this e-mail to be a
>>> starting point for discussion.
>>>
>>> I suppose the current intention is to make the legacy provider as
>>> opt-
>>> in only by either application explicitly loading it or by having it
>>> added to the default configuration file.
>>
>> The current plan is that if no provider is loaded by the time the
>> first "fetch"
>> is done, then then "default" provider gets loaded automatically. In
>> other words
>> the "legacy" provider won't get loaded automatically *unless* it is
>> loaded by
>> the default configuration file.
>>
>> I don't recall any discussion about what will be in the default
>> configuration
>> file. My assumption has always been that the legacy provider would
>> not be
>> automatically loaded.
>>
>>> Is there anywhere any document which categorizes the current set of
>>> algorithms with which are considered legacy and which not?
>>
>> The algorithms planned to be moved to the legacy provider are:
>>
>> Blowfish
>> CAST
>> DES (but not 3DES)
>> DSA
>> IDEA
>> MD2
>> MD4
>> MDC2
>> RC2
>> RC4
>> RC5
>> RIPEMD160
>> SEED
>> Whirlpool
>>
>> This is documented in the "Legacy Provider Module" section of the
>> Design Document:
>>
>> https://www.openssl.org/docs/OpenSSL300Design.html
>>
>> Note the following caveat that document has about the above list:
>>
>> "this is not meant to be an exhaustive list, even though fairly
>> complete for the
>> moment"
>>
>>> I understand that for the current digest algos implemented in the
>>> legacy provider the problem might not be as pressing as these
>>> algorithms are not widely used however which other algorithms are
>>> going
>>> to be moved into the legacy provider?
>>
>> My guess is that the ones likely to give us the most problems would
>> be DES, DSA
>> and RC4
>>
>>> Wouldn't it be better to make the legacy provider opt-out? I.E.
>>> require
>>> explicit configuration or explicit API call to not load the legacy
>>> provider.
>>>
>>
>> IMO this is a major release and therefore we should be taking the
>> opportunity to
>> encourage applications to move away from these legacy algorithms.
>> That's kind of
>> the point of having a legacy provider in the first place. Most
>> applications
>> should not need to use these legacy algos so in my mind it is a
>> sensible default
>> to not have them available. Only if you *really* need them should you
>> load the
>> legacy provider.
> 
> OK, but then for the applications that *really* need the legacy
> algorithms the move to 3.0.0 will definitiely not be just a
> recompilation.

It can still be a simple recompilation even in this case - combined with a
configuration change.

> But then I agree with the notion that the default config file should
> not load the legacy provider. Otherwise we will see very mixed reports
> of what legacy applications fail or not based on whether the legacy
> application loads the default configuration file or not,

The plan is to change things so that the configuration file is *always* loaded
by default. So even if an application didn't explicitly load it before - they
will do with 3.0.

> whether the
> default configuration file was updated with the new version that loads
> the legacy provider, etc. etc.
> 
> So to encourage the right implementation of legacy apps perhaps the
> openssl application (here by adding a -legacy option for example?) and
> the test apps should explicitly load legacy provider if asked to work
> with legacy algorithm.

I do think the openssl apps need to have some option to make them work with
legacy algos ("-provider legacy" perhaps).

Matt