like SSLv3 is enabled for httpd in spec?] Message-ID: <20160306090225.c68ce12825@37545b1a29b4c14> Reply-To: In-Reply-To: <[email protected]>
* Adi Kriegisch <[email protected]> [04/03/2016 21:36:16] wrote: > Hi! > > > > I'm not exactly sure what the camellia crap is doing there and > > > this > > > looks fishy and overly complicated to me in many ways, but > > > anyway: > > Because - you know - what if AES is backdoored by NSA or > > something. > Oh well... It all began with removing weak ciphers; at the time > the ecrypt > paper stated that CAMELLIA as well as AES was just fine. > Now as Firefox/Thunderbird dropped support, removing CAMELLIA is > just fine. > I've noted before that my issue is also that CAMELLIA has seen a lot less cryptanalysis (especially in recent years) than AES. Because it was mentioned earlier: eh ECRYPT document is excellent but written by Cryptographers, it does not consider practical issues with recommendations they make regarding ciphers (e.g. quality of OpenSSL implementations, performance and hardware support). We're well off with AES in my opinion and anyone that believes otherwise should make a serious attempt at explaining his believes in detail, backing them up with papers and appropriate arguments. So far we're at: CAMELLIA goes. Before we do that I'll take another look at the cipherstring in general and encourage everyone to do so. Test with current OpenSSL releases as their parsing and interpretation of the cipherstring might have changed (for the better) again. I'll do the same. > > While we're add it; especially for HTTPS: I think it would make > > a lot of sense to get rid of the Cipherstring-A. It's not used > > anywhere in the actual Applied Crypto Hardening document and I > > think current browsers will have a hard time establishing any > > connection with that preferred suite. > Actually cipherstring A was never meant to be defined by us. It > was > meant to be defined by the admin who knows more about the > environment > and the clients connecting whereas cipherstring B was designed to > work > 'everywhere' -- a secure, general purpose cipher string that works > with > OpenSSL v0.9.8 as well as v1.0.2. Yes, I remember. The general idea was that if e.g. a admin has good control over large parts of his infrastructure (i.e. clients as well) he might want to shorten the cipherstring significantly, only allowing a few, very modern, ciphers. The idea is good and we should keep it in there. But there're two problems currently with it: a) it's called 'cipherstring-a' which is a bit misleading as we're not actually providing anything like a cipherstring. we should keep the recommendation in there but change the title around. For example controlled-environment-cipherstring. But maybe someone finds a slicker name, I'm not good at naming things. b) We should discuss the following issue; do we want to encourage Administrtors to take action and deploy their own cipherstring? We've seen how difficult it is to get this right and working with different OpenSSL-branches and software environments. I'd actually actively discourge that. And if someone knows enough to do so anyway, he probably doesn't need our document but will want to refer to the ECYPT reference directly, or look up newer documents released by various researchers and organizations in that direction, certainly this is not something we even try to supply as it's outside of our expertise and project scope. > I rather believe we should rename cipherstring B to C and define a > next > generation cipherstring B using something like OpenSSL v1.0.1 as a > baseline > (we, of course, need to evaluate current distributions and the > OpenSSL > versions used there). Let's just call cipherstring-b: BetterCrypto CipherString? What do you think? Aaron
signature.asc
Description: Digital signature
_______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
