<div dir="ltr"><div><span style="font-family:arial,helvetica,sans-serif">Hi,<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">what do you think about discussing the cipher policy with </span><br><span style="font-family:arial,helvetica,sans-serif">
concrete proposals? <br></span><div><div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">I'd like to contribute this policy for ciphers to the discussion:<br>
</span></div><div><span style="font-family:arial,helvetica,sans-serif">* Highest Priority for Ciphers that support '</span>Forward Secrecy'<br></div><div>* Favor DHE over ECDHE (with a hint to check the performance)<br>
</div><div>* Favor GCM over CBC regardless of the cipher size<br></div><div>* Priorize the ciphers by the sizes of the Cipher and the MAC<br></div><div><div>* Favor RSA over ECDSA <br></div>* Append the list with Ciphers for legacy browsers and web crawlers <br>
</div><div>* Do not use RC4, MD5,... etc<br>* Ciphers should be usable for DH >= 2000 bits, without blocking latency browsers<br></div><div></div><div></div><div><span style="font-family:arial,helvetica,sans-serif"><br>
</span></div><div>Conrete this results in this ciphers (grouped according above policy):<br></div><div><span style="font-family:courier new,monospace">TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)<br>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)<br>
-------------------------------------------------<br>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)<br>TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)<br>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)<br>=================================================<br>
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)<br>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)<br>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)<br>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)<br>-------------------------------------------------<br>
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)<br>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)<br>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)<br>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)<br>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)<br>
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)<br>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)<br>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)<br>=================================================<br>TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)<br>
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)<br>-------------------------------------------------<br>TLS_RSA_WITH_AES_256_CBC_SHA (0x35)<br>TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)<br>TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)</span><br><span style="font-family:courier new,monospace"><br>
<span style="font-family:arial,helvetica,sans-serif">This could be reached by this cipher string:</span><br>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</span><br><br>Remarks:<br>'-<span style="font-family:courier new,monospace">DHE-RSA-AES128-SHA':<span style="font-family:arial,helvetica,sans-serif"> used to be able to use </span></span><span style="font-family:arial,helvetica,sans-serif">DH >= 2000 bits, without blocking latency browsers</span><br>
<span style="font-family:courier new,monospace">'DHE-RSA-AES256-SHA': <span style="font-family:arial,helvetica,sans-serif">for compatibility reasons for elder versions of openssl</span></span><span style="font-family:arial,helvetica,sans-serif"></span><br>
<br></div><div>What do you think about this proposal? Which recommendations do you see?<br></div><div>Kind regards <br><br></div><div>Torsten<br></div><div><br>More Info in German (DRAFT!):<br><a href="https://www.owasp.org/index.php/Germany/Projekte/Top_10_fuer_Entwickler-2013/A6-Verlust_der_Vertraulichkeit_sensibler_Daten">https://www.owasp.org/index.php/Germany/Projekte/Top_10_fuer_Entwickler-2013/A6-Verlust_der_Vertraulichkeit_sensibler_Daten</a><br>
(Verteidigungs-Option 2a gegen 'Verlust der Vertraulichkeit sensibler Daten')<br><br><div class="gmail_extra"><div class="gmail_quote">2014-04-02 22:29 GMT+02:00 Aaron Zauner <span dir="ltr"><<a href="mailto:azet@azet.org" target="_blank">azet@azet.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While we're at it, could we get rid of camellia as well?<br>
<br>
        * no constant time implementation<br>
        * no extensive cryptanalysis - at least not as extensive as AES<br>
        * not actively used anywhere as far as I'm aware of<br>
<br>
Aaron<br>
<br>
Aaron Zauner wrote:<br>
> Hi,<br>
><br>
> For a current GitHub thread I'm involved in where I suggested use of our<br>
> cipher recommendations (<a href="https://github.com/puppetlabs/puppet/pull/2494" target="_blank">https://github.com/puppetlabs/puppet/pull/2494</a>)<br>
> I have compiled an ancient version of OpenSSL and just noticed that the<br>
> 'IDEA' cipher (weak keys) does pop up there.<br>
><br>
> Can we include a `!IDEA` in the cipher spec at the end please?<br>
><br>
> Aaron<br>
><br>
<br>
<br>_______________________________________________<br>
Ach mailing list<br>
<a href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a><br>
<a href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach" target="_blank">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a><br>
<br></blockquote></div><br></div></div></div></div></div>