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

[hkario@redhat.com]

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