Re: (ITS#8211) ssf does not reflect actual security of connection

[hyc@symas.com]

hkario@redhat.com wrote:
> Full_Name: Hubert Kario
> Version: all
> OS: Linux
> URL:
> Submission from: (NULL) (213.175.37.10)
>
>
> Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one
> (>1) roughly correlates to the effective encryption key length.". This is not
> the case more often than not.
>
> Problem is that ssf as it is calculated now doesn't take into consideration
> all the cryptographic primitives in use.
>
> In other words, a connection that uses a 512 bit RSA certificates and
> negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not
> provide security equivalent to "modern strong ciphers"[2][3] and should be
> awarded "256".
>
> Similarly a connection that uses 512 bit DH parameters and negotiates
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide
> security that should be awarded "256"[5].
>
> In fact, recommending use of high key sizes[2] will cause the connection to
> use _less_ secure CBC ciphersuites[5] with clients that support AEAD
> ciphersuites with AES-128 only (like Thunderbird and Firefox do).
>
> Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers
> disagree[6].
>
>
> So I think either:
>   1). ssf needs to be redefined to consider any value higher that "2" to be
>       equal, and requiring the server administrators to enable only
>       ciphersuites they consider secure, or
>   2). the whole code that calculates ssf needs to be updated to take into
>       account many more things:
>       * use of AEAD
>       * use of Encrypt-then-MAC
>       * the protocol version used (both because TLS1.0 specific attacks[7] as
>       wewell as the use of SHA1+MD5 for signatures which limits the connection
>         security to 80 bits[8] (optimistically) if client certificates are in
>         use in TLS < 1.2)
>       * encryption algorithm on session tickets
>       * current state of attacks on a given ciphersuite
>       * the size of ECDHE curve, FFDHE prime or server certificate key size,
>         depending on ciphersuite negotiated
>       * the signature algorithm used in Certificate Verify message
>       * the key size of client certificate
>       * the signature on the client certificate and key sizes in CA
>         certificates
>       * the HMAC used
>       * key size of the symmetric cipher
>       * (probably other things I didn't think about)
>
>   1 - http://www.openldap.org/doc/admin24/security.html
>   2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9
>   3 - https://freakattack.com/
>   4 - https://weakdh.org/
>   5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html
>   6 - https://tools.ietf.org/html/rfc7465
>   7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
>   8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

Patch welcome. Either a doc patch describing your option (1) or a code patch 
for your (2). Note that SSF generally comes to us from SASL, so a code patch 
most likely needs to be submitted to the Cyrus-SASL Project, not us.

Overall the definition of SSF has been in use in the industry for many years; 
it's not something we created or control. Changing the description or 
definition of it likely needs to also happen elsewhere.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/