[email protected] 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/
