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