[Ach] Proposal to change B cipher spec

Aaron Zauner azet at azet.org
Fri Apr 4 02:37:50 CEST 2014


Hi Torsten,

First off: Why wouldn't the OWASP project simply refer to other projects
concerning cryptography recommendations (ENISA, bettercrypto [...])?
This might spare you hours of valuable time.

Torsten Gigler wrote:
> I'd like to contribute this policy for ciphers to the discussion:
> * Highest Priority for Ciphers that support 'Forward Secrecy'
> * Favor DHE over ECDHE (with a hint to check the performance)
ACK.

> * Favor GCM over CBC regardless of the cipher size
ACK. CBC mode in TLS <1.1 will be vulnerable to the BEAST attack.

> * Priorize the ciphers by the sizes of the Cipher and the MAC
How do you prioritize those? The MAC has to fit the security of the
symmetric algorithm in question.

> * Favor RSA over ECDSA
ACK.

I have recently come to the conclusion that - basically - djb pointed to
and solved most problems 10years before the wider community and
implementors notice them. Of course this is a generalization - and not
always true (TCP SYN cookies) - but it's mostly true. The issue being
that you need more feedback than djb to standardize stuff. :)

Ed25519 looks really nice. But it's not deployed anywhere near TLS, as
far as I know. See: https://en.wikipedia.org/wiki/EdDSA

related hint (off topic, I know): DNSSEC DDOS will become a real problem
in the next couple of years. I've talked to Dan Kaminsky on twitter
about the issue. His basic response was "but other protocols suck as
well!". Without starting another flame: this is just naive. Have fun
with a badly designed, hierarchical, "trust" protocol. As such DANE
seems to be doomed as well.

> * Append the list with Ciphers for legacy browsers and web crawlers
> * Do not use RC4, MD5,... etc
> * Ciphers should be usable for DH >= 2000 bits, without blocking latency
> browsers
> 
> Conrete this results in this ciphers (grouped according above policy):
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
Basically you'll need SHA512 to fit the security level of AES256. We
have this issue as well. No SHA512 in TLS :)

> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
> -------------------------------------------------
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
SHA-1: 160bit. You'll need a cryptographic hash function of 512 bit to
match the security of the symmetric cipher (AES). As well as appropriate
RSA/DH params.

> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
> =================================================
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
See above.

> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
DSA is a bad standard, as is DSS. ECDSA seems to be even more broken:
http://blog.cr.yp.to/20140323-ecdsa.html


> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
> -------------------------------------------------
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
> =================================================
> TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
> TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
> -------------------------------------------------
> TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
> 
> This could be reached by this cipher string:
> openssl ciphers -V
> EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:-DHE-RSA-AES128-SHA:EECDH+AESGCM:EECDH+AES:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA
> 
> Remarks:
> '-DHE-RSA-AES128-SHA':used to be able to use DH >= 2000 bits, without
> blocking latency browsers
> 'DHE-RSA-AES256-SHA': for compatibility reasons for elder versions of
> openssl
I don't really follow there, regarding the "DH >= 2000 bits".


Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140404/dc3aff02/attachment.sig>


More information about the Ach mailing list