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
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/
changed state Open to Feedback
moved from Incoming to Software Bugs