Re: [TLS] Deprecating more (DSA?)

[Brian Sniffen <[e-mail]>]

Alyssa Rowan <[e-mail]> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> It looks like RC4 is rapidly heading for the chopping block, with
> basically unanimous consensus. Good.

Agreed, mod Martin's proposal that I understand to ask for a reasonable
path by which we strongly deprecate RC4 on clients, then after a client
generation ban RC4 on clients and deprecate for servers.

> On 15/04/2014 14:34, Hanno Böck wrote:
>
>> What other algorithms exist in the TLS spec that should see
>> deprecation? […] E.g. what about deprecating DSA?
>
> I actually favour, for reasons of complexity and weakness, potentially
> deprecating pretty much everything that falls in the following lists,
> if of course it isn't already deprecated, subject to discussion:
>
> • Anything with NULL anything
>   - An accident waiting to happen (on purpose).

We have seen between 300 and 400 customers configure eNULL or aNULL
ciphers using OpenSSL cipher strings like "HIGH:-MEDIUM:-LOW".  None
intended it when asked.

Agreed without comment on EXPORT, DES, IDEA, MD5, DSS/DSA.

3DES is currently the one cipher supported by old clients and new
servers.  Its block size is too small, but we need to do more to provide
a path out for people currently stuck using it.

ECDSA and SHA-1 must both live until ECDSA/RFC6979 or EdDSA (and SHA-2
or SHA-3) are in common use; it doesn't do anyone any favors to churn
that faster than new implementations can become common.  What's the
right time-line for that?

> • RSA without forward security
>   - Seems like we're heading broadly in the direction of requiring
>     forward-security, which means deprecating plain old RSA in TLSv1.3
>     negotiations? Thoughts?

This will drive performance-sensitive providers of bulk, non-secret data
to stick with TLS 1.2 for years.  That may be okay.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies