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

2019-07-19 Thread Benjamin Kaduk
On Mon, Jul 15, 2019 at 02:19:22PM +0100, Matt Caswell wrote:
> 
> 
> On 15/07/2019 13:58, Tomas Mraz wrote:
> 
> > 
> > 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

To add a bit of anecdata, Debian and Fedora are removing DES support from
(MIT) krb5.  So far all we've seen as bug reports are that the kernel may
still have that enctype in its list to use for NFS (as well as other,
still-useful, ones), and so we need to ignore it instead of bailing.
But given that it provides only ca. $20 of protection, it's not especially
surprising that we aren't seeing much using it.

On the other hand, krb5 is not going around and disabling RC4, even though
RFC 8429 is a thing.

-Ben


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

2019-07-17 Thread Tim Hudson
My view point (which has been stated elsewhere) is that OpenSSL-3.0 is
about internal restructuring to allow for the various things noted in the
design documents.
It is not about changing the feature set (in a feature reduction sense).

In future releases we will make the mixture of providers available more
capable and may adjust what algorithms are available and may even do things
like place national ciphers in separate providers.
But OpenSSL-3.0 is *not* the time to do any of those things.

We should be focused on the restructuring and getting the FIPS140 handling
in place and not making policy decisions about changing algorithm
availability or other such things.
The objective is that the vast majority of applications that use
OpenSSL-1.1 can use OpenSSL-3.0 with a simple recompilation without any
other code changes.

That I believe has been our consistent out-bound message in discussions as
a group and our overall driver.

In the future, things may become more dynamic and we may change the
algorithm sets and may use more configuration based approaches and may even
place each algorithm in a separate provider and allow for a whole range of
dynamic handling.
But those are for the future. OpenSSL-3.0 is basically an internally
restructured version of OpenSSL-1.1 with a FIPS140 solution.

Tim.


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

2019-07-17 Thread Salz, Rich
>  If DSA is almost never used, why enable it by default?

I am amused/bemused that, after years of saying we do not know what people are 
doing with OpenSSL, it now is now becoming common practice to blithely assert 
"this is not used" when it fits the personal viewpoint of some folks.




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

2019-07-16 Thread Kurt Roeckx
On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote:
> On Mon, Jul 15, 2019 at 02:27:44PM +, 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.
> > 
> > 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.
> 
> 1.  DSA is not supported in TLS 1.3.
> 2.  DSA is almost never used with TLS 1.2, the public
>   CAs and the vast majority of users employ RSA.
> 3.  Historical DSA was limited to 1024-bit keys and SHA-1.
>   IIRC we now support stronger combinations, but these
>   are not widely used.
> 4.  As mentioned key disclosure is more likely than with RSA.
> 5.  Attack-surface reduction.  If DSA is almost never used,
>   why enable it by default?
> 
> I might note that I don't count myself amont the "crypto maximalists"
> And I'm generally of the "raise the ceiling not the floor" mindset,
> RFC7435 and all that.  However, once an algorithm is sufficiently
> disused (raising the ceiling worked, and everybody we care about
> has moved on) it is then time to turn out the lights.

There used to be DSA certificates used in TLS, but the last one
expired years ago. DSS based ciphers are also disabled by default
since 1.1.0.


Kurt



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

2019-07-16 Thread Viktor Dukhovni
On Mon, Jul 15, 2019 at 02:27:44PM +, 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.
> 
> 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.

1.  DSA is not supported in TLS 1.3.
2.  DSA is almost never used with TLS 1.2, the public
CAs and the vast majority of users employ RSA.
3.  Historical DSA was limited to 1024-bit keys and SHA-1.
IIRC we now support stronger combinations, but these
are not widely used.
4.  As mentioned key disclosure is more likely than with RSA.
5.  Attack-surface reduction.  If DSA is almost never used,
why enable it by default?

I might note that I don't count myself amont the "crypto maximalists"
And I'm generally of the "raise the ceiling not the floor" mindset,
RFC7435 and all that.  However, once an algorithm is sufficiently
disused (raising the ceiling worked, and everybody we care about
has moved on) it is then time to turn out the lights.

So what are the reasons for *keeping* DSA enabled by *default*
(at runtime)?  Compile-time still delivers the legacy module,
and the configuration file can enable it with no recompilation.

-- 
Viktor.


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

2019-07-16 Thread Kurt Roeckx
On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote:
> 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.

I'm not even sure why they need to move to a different provider
(at this time). Instead I think we should have a mechanism to
enable/disable the individual algorithms, and still have
everything in the default provider, possibly disabled by default.

At some point in the future we could remove the code from OpenSSL,
and move it to different repository that only contains such legacy
code that we no longer ship as part of OpenSSL.

Kurt



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