Re: [TLS] Deprecating more (DSA?)

["Joseph Salowey (jsalowey)" <[e-mail]>]

I'm not to crazy about deprecating DSA in the same fashion as RC4.  I'd be fine with leaving DSA/DSS out of TLS 1.3 if there is support for that.  I like the list below, some comments inline:

On Apr 16, 2014, at 3:36 PM, Alyssa Rowan <[e-mail]> wrote:

> Signed PGP part
> 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).
> 

[Joe] Many cipher suites with NULL encryption have been added in the recent past.   I think we'll need to have more discussion on that.  I don't not currently have data on how widely they are used. 

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

[Joe] yup.  

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

[Joe] not sure about this one.  I think the argument in keeping 3DES around is as a fallback to AES.  Not sure I buy into this, especially if we have a better alternative, perhaps CHaCha.  

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

[Joe] yes to the above.  Perhaps there still is DSS in use, but I really would expect that to move to ECDSA.  

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

[Joe] I think I'd like to bring ECDH and ECDSA into the core spec in 1.3.  We could make some of these changes as part of that.  

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

[Joe] yup

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

[Joe]  Why not? 


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

[Joe] Not sure.  

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

[Joe] I didn't see much objection to removing plain old RSA in the call for consensus. 

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

[Joe]  So, at this point I'd rather see 1.3 have a way to negotiate parameters than deprecate DHE entirely.  I'm not sure that I have a really good reason to keep DHE around other than I'm more comfortable with it.  

> 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
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls