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 Matt Caswell



On 16/07/2019 19:19, Kurt Roeckx wrote:
> 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.

I think the reasoning behind having the legacy provider was as a first step to
doing just that, i.e. we move the legacy stuff to a legacy provider and then at
some later point we could choose to separate out the legacy provider as a
separate thing which we don't release with mainline OpenSSL - but if people want
to add it back in then they download and build the legacy provider separately
and just drop it back in and it automatically becomes available again.

Matt


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