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

2019-07-15 Thread Tomas Mraz
On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote:
> On Mon, 15 Jul 2019 16:15:01 +0200,
> Tomas Mraz wrote:
> > So saying this is "just recompliation and configuration change" is
> > at least somewhat oversimplified.
> > 
> > But I am OK with that. I'm just saying it should be better
> > advertised
> > and that internally openssl should not use the "load legacy
> > provider by
> > having it in default config file" to actively encourage the "load
> > legacy provider only if you *really* need it" behavior.
> 
> I'm a little confused.  "configuration changes" is about "having it
> in
> the config file", so I don't quite understand "oversimplified".

Basically no application that would like to work with algo from legacy
provider and that always needs it to work properly - let's say for
example something that needs to connect legacy Windows shares which use
MD4 to compute some password hash - that application cannot depend on
having the legacy enabled in the openssl config file. It should
explicitly load the legacy provider.

> Regardless of where this discussion gets us, it has always been the
> aim that this will be configurable with the config file.

Sure. What I'm just saying is that having it configurable does not
always mean it can be depended on.

I can see for example an application that works with various hashes and
by default uses secure ones and you as user need the app to check some
old file with old MD4 or RIPEMD160 hash as an exception - this can be
done by the user enabling the legacy provider in the openssl config
file.

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




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

2019-07-15 Thread Salz, Rich
>>DSA
> 
> What is the cryptographic weakness of DSA that you are avoiding?

It's a good question. I don't recall the specific reason why that was added 
to
the list. Perhaps others can comment.

The only weakness I know about is that if you re-use the nonce, the private key 
is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4.

I think this should be removed from the "legacy" list unless someone can point 
out why it's like the others in the list.




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

2019-07-15 Thread Richard Levitte
On Mon, 15 Jul 2019 16:15:01 +0200,
Tomas Mraz wrote:
> 
> So saying this is "just recompliation and configuration change" is
> at least somewhat oversimplified.
>
> But I am OK with that. I'm just saying it should be better advertised
> and that internally openssl should not use the "load legacy provider by
> having it in default config file" to actively encourage the "load
> legacy provider only if you *really* need it" behavior.

I'm a little confused.  "configuration changes" is about "having it in
the config file", so I don't quite understand "oversimplified".

Regardless of where this discussion gets us, it has always been the
aim that this will be configurable with the config file.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


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

2019-07-15 Thread Matt Caswell



On 15/07/2019 15:15, Tomas Mraz wrote:
> On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
>>
>> 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:
>
 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.
> 
> This might be fine for a special build of openssl included within an
> application. But what would you recommend for a distribution wide
> openssl?
> 
> If the legacy provider is not supposed to be loaded for normal
> applications then the system-wide configuration file must not load the
> provider. And then you have the special legacy apps that need it and so
> they need to explicitly load the legacy provider. So saying this is
> "just recompliation and configuration change" is at least somewhat
> oversimplified.

Agreed. There will certainly be cases where code change *is* required. I'm just
saying that not all apps will have to do this.

> 
> But I am OK with that. I'm just saying it should be better advertised
> and that internally openssl should not use the "load legacy provider by
> having it in default config file" to actively encourage the "load
> legacy provider only if you *really* need it" behavior.
> 

Also agreed. I don't think we should load it in the default config file. We
*should* provide an option to the apps to enable it to be loaded on a
case-by-case basis where appropriate.

This will certainly need some explaining at some point. As will the whole
concept of providers and how the new architecture works.  I expect to see
(eventually) blog posts/wiki pages/man pages/CHANGES entries about the whole
provider thing - and that will have to include the concept of the legacy 
provider.

Matt


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

2019-07-15 Thread Tomas Mraz
On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
> 
> 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:
> > > > 
> > > 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.

This might be fine for a special build of openssl included within an
application. But what would you recommend for a distribution wide
openssl?

If the legacy provider is not supposed to be loaded for normal
applications then the system-wide configuration file must not load the
provider. And then you have the special legacy apps that need it and so
they need to explicitly load the legacy provider. So saying this is
"just recompliation and configuration change" is at least somewhat
oversimplified.

But I am OK with that. I'm just saying it should be better advertised
and that internally openssl should not use the "load legacy provider by
having it in default config file" to actively encourage the "load
legacy provider only if you *really* need it" behavior.

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




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

2019-07-15 Thread Salz, Rich

>DSA

What is the cryptographic weakness of DSA that you are avoiding?

 



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

2019-07-15 Thread Matt Caswell



On 15/07/2019 14:46, Salz, Rich wrote:
> 
>>DSA
> 
> What is the cryptographic weakness of DSA that you are avoiding?

It's a good question. I don't recall the specific reason why that was added to
the list. Perhaps others can comment.

Matt



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

2019-07-15 Thread 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



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

2019-07-15 Thread 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.]




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

2019-07-15 Thread Matt Caswell



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.

Matt


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

2019-07-15 Thread Tomas Mraz
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.

Is there anywhere any document which categorizes the current set of
algorithms with which are considered legacy and which not?

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?

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.

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