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

[Viktor Dukhovni]

On Mon, Jul 15, 2019 at 02:27:44PM +0000, 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.