[Ach] Proposal to change B cipher spec

Torsten Gigler torsten.gigler at owasp.org
Thu Apr 3 13:20:59 CEST 2014


Hi,

what do you think about discussing the cipher policy with
concrete proposals?

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)
* Favor GCM over CBC regardless of the cipher size
* Priorize the ciphers by the sizes of the Cipher and the MAC
* Favor RSA over ECDSA
* 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)
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)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
=================================================
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
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

What do you think about this proposal? Which recommendations do you see?
Kind regards

Torsten

More Info in German (DRAFT!):
https://www.owasp.org/index.php/Germany/Projekte/Top_10_fuer_Entwickler-2013/A6-Verlust_der_Vertraulichkeit_sensibler_Daten
(Verteidigungs-Option 2a gegen 'Verlust der Vertraulichkeit sensibler
Daten')

2014-04-02 22:29 GMT+02:00 Aaron Zauner <azet at azet.org>:

> While we're at it, could we get rid of camellia as well?
>
>         * no constant time implementation
>         * no extensive cryptanalysis - at least not as extensive as AES
>         * not actively used anywhere as far as I'm aware of
>
> Aaron
>
> Aaron Zauner wrote:
> > Hi,
> >
> > For a current GitHub thread I'm involved in where I suggested use of our
> > cipher recommendations (https://github.com/puppetlabs/puppet/pull/2494)
> > I have compiled an ancient version of OpenSSL and just noticed that the
> > 'IDEA' cipher (weak keys) does pop up there.
> >
> > Can we include a `!IDEA` in the cipher spec at the end please?
> >
> > Aaron
> >
>
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140403/dd63560a/attachment.html>


More information about the Ach mailing list