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

[Kurt Roeckx]

On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote:
> 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.

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