Re: [TLS] Deprecating more (DSA?)

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

It looks like RC4 is rapidly heading for the chopping block, with
basically unanimous consensus. Good.

In the meantime...

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

• Anything EXPORT
  - Bad old days. Kill them with fire. TLSv1.1 deprecated them but
    didn't forbid them in TLSv1.0; if they're not already a MUST NOT
    somewhere, I think they should be.

• DES is already deprecated. [RFC5469]
  - What about 3DES now?

• IDEA's already deprecated. [RFC5469]
  - Little traction in the wild, due to the (now-expired) patents.

• Anything using MD5
  - Collided. Kill it off. I'd feel highly uncomfortable keeping this
    around.

• Anything using DSS/DSA certs
  - The Nonce Problem. RFC 6979 fixes this, but...
  - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? ¬_¬

• ECDSA without RFC6979?
  - Because of The Nonce Problem.
  - Remember to avoid timing attacks in RFC6979.
  - I don't know where that stands regarding FIPS-compliance, for those
    that need it: but as far as I'm concerned, if FIPS is incompatible
    with RFC6979, FIPS needs fixing because it's encouraging extremely
    fragile implementations.
  - ECDSA makes me uneasy now. It shares DSA's characteristics of being
    fragile as hell. I can't help but worry it was intentionally
    designed that way.
  - We will need a new scheme soon; EdDSA or a very similar
    Schnorr-style derivative? I'd like EdDSA swapping SHA-256 for
    SHA-3, perhaps? A discussion for the future (and/or CFRG, etc).

• Anything using SHA-1?
  - Already deprecated by NIST, and by CAs and vendors in certificates
    due to ~2^61 being expensive but practical.
  - An attack is harder in a MAC scenario - but it's only a matter of
    time; it's downhill all the way from here.
  - Thoughts?
  - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and down?

• DH_anon?
  - Subject to thoughts about possible opportunistic encryption,
    although this definitely isn't the way you _want_ to do that.

• Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why?

• 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?

• DHE
  - Given the complexities noted surrounding DHE parameters and lack of
    ability to negotiate them, would we be better off dropping
    conventional DHE for TLSv1.3?
  - Favour ECDHE over secp256r1 and/or Curve25519 (where the latter
    is not forbidden by FIPS-compliance, with 25519 being preference)
    as baseline instead?

I do realise that's a strongly aggressive proposed unused-feature or
not-best-practice cull, largely for reasons of complexity reduction.
Perhaps others will be able to moderate my opinions. :-)

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTTwXdAAoJEOyEjtkWi2t6fGkP/3C1+/o7QOSU2Gu0wdiYnsZ7
6zKCszf954w0mYIugZdwkKI6ZxlgjcybWz9ZFRPoXaf9XFlJgFRK+YysgmGFlmmO
qJNsv/ur14JSWMClUuD/BH5EKpDlY9jOAFt44k6RIf8dZN7B1CO9yhjUMnlwdh8J
MZuGLywu7She9JfIbhcBGVfXMYlExy7nI857K7YkbAu0LZdWNNV3Ut0VEYBq2feB
tyMuuSq3Jdv00A52PfMjT5INEAHZGOH3yKbaY0yPY7HDhpcMGjD1YmeVN++wHD8X
1jOlxS6wWWP59ifRmsLIRH7oZvCGXs4oM0RO0T22Ou2424g73Uwccmqhc9jDebdz
0E/srZ3W4gan4kkvBgNwAEBxiQ/rxg0Haab6vnvusBpkO4n78Dy41dt046V/tEWn
1W44nVZ+wNRM+78xlKD+72k2BG3k3nOpszQfS+b024PaIhLGMLAbd3no/V9EQVsc
vvN3tMM4wTVQm3ZyUHetxn1BqBrxRYeydsnGiGjDKWA7YLTC79S2E6ADLYv7OeT8
6cc33QLKogoSlm/KfUqH7FAZKr0uNbkf3zKVwuKLSlqFAl6l6AMlGhnP+FyekXIQ
vp27MxZyFX1V8PLjHFzUlrRfeg02GrsXjl3wcsh4/OTftGA3clPw5GH0U9Apy3Zr
F4DoDtMHy88ukdTKybKc
=gD5B
-----END PGP SIGNATURE-----