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

[Tomas Mraz]

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.

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, 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.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]