<div dir="ltr">Hello,<div><br></div><div>Regarding AES, I would definitively remove the "!AES128".</div><div><br></div><div>I agree with earlier discussion that lead to promote AES256 (even if it's disputable if it's really the most secure choice).</div>
<div>I need that shouldn't reject AES128.</div><div><br></div><div>Btw, AES128 is the only choice in a lot of default appliances / softwares / API... like</div><div>- Oracle Java on Linux and Windows (Apple was allowing AES256, still the case?)</div>
<div>- IPSec on iPhone (and Mac OS X but need to be checked)</div><div>- ...</div><div><br></div><div>In my personal opinion, I would stick to AES256 as recommendation. That's the choice we made and that we explain.</div>
<div>But I would keep AES128 in the list of known secured algorithm as we have no clue that it could have been broken.</div><div><br></div><div>Kr,</div><div><br></div><div>David</div><div><br></div><div><br></div></div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">2013/11/26 Philipp Gühring <span dir="ltr"><<a href="mailto:pg@futureware.at" target="_blank">pg@futureware.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi,<br>
<div class="im"><br>
> Hi,<br>
><br>
> Philipp, thanks for your commits in<br>
><br>
<a href="https://git.bettercrypto.org/ach-master.git/commitdiff/bb3bcb346b58ae227e0534e070e7f1682044b024" target="_blank">https://git.bettercrypto.org/ach-master.git/commitdiff/bb3bcb346b58ae227e0534e070e7f1682044b024</a><br>
><br>
> While I see many great corrections and fixing of typos I have<br>
nevertheless two requests why I'd like to see this commit reverted for<br>
the moment (not for ever!)<br>
><br>
><br>
><br>
> 1) In the future, please use individual commits instead of one big one<br>
where you changed a lot. This is much easier to compare and check (yes,<br>
I actually cross check every commit). But this is more of a formalism.<br>
<br>
</div>After I did all the changes, unfortunately, I ran out of time, and when<br>
wanted to commit it, and noticed that I should have commited each change<br>
itself, not the whole bunch together, but then I did not had enough time<br>
anymore, to split the changes up again. Unfortunately my timeslots have<br>
been very small lately, so I am happy that you were able to cope with<br>
it, and I am sorry for the confusion that caused.<br>
<div class="im"><br>
><br>
><br>
> This is important:<br>
><br>
> 2) We established a tradition here to really discuss cipher string<br>
recommendations.<br>
> So, please first discuss with us why you changed:<br>
><br>
> diff --git a/src/practical_settings.tex b/src/practical_settings.tex<br>
> index 67570b4..23bf018 100644 (file)<br>
> --- a/src/practical_settings.tex<br>
> +++ b/src/practical_settings.tex<br>
> @@ -22,7 +22,7 @@<br>
> # ALL subdomains HAVE TO support https if you use this!<br>
> # Strict-Transport-Security: max-age=15768000 ; includeSubDomains<br>
><br>
> - SSLCipherSuite<br>
'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'<br>
> + SSLCipherSuite<br>
'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'<br>
> \end{lstlisting}<br>
><br>
><br>
> (in short: you removed the "!SRP" part).<br>
> While your change might be 100% correct, great and we really made a<br>
mistake, it pays off to discuss this internally first.<br>
<br>
</div>We had a discussion about SRP 2 weeks ago here:<br>
<a href="http://lists.cert.at/pipermail/ach/2013-November/000141.html" target="_blank">http://lists.cert.at/pipermail/ach/2013-November/000141.html</a><br>
<a href="http://lists.cert.at/pipermail/ach/2013-November/000145.html" target="_blank">http://lists.cert.at/pipermail/ach/2013-November/000145.html</a><br>
<a href="http://lists.cert.at/pipermail/ach/2013-November/000161.html" target="_blank">http://lists.cert.at/pipermail/ach/2013-November/000161.html</a><br>
and I did not got any negative feedback within a week, so I thought that<br>
it should be fine to change it.<br>
<br>
Perhaps I need to explain some more, why I think that we should remove !SRP:<br>
TLS-SRP is a cipher-suite that provides security against<br>
man-in-the-middle attacks, since it intrinsically needs both client and<br>
server to authenticate each other, and it provides security against<br>
compromised CA´s and other faked certificates.<br>
We are currently still waiting for the browser,... vendors to fully<br>
implement SRP (which is quite complicated, but they are working on it),<br>
therefore SRP is currently not needed, but when the clients are ready,<br>
people will want to use it, and when having !SRP in the paper will give<br>
them the impression that SRP is insecure, perhaps without having a good<br>
reason for it.<br>
I think we need a good reason for writing !SRP into the paper. Does<br>
anyone have a good reason for it?<br>
<br>
<br>
While we are at changing the ciphersuites: What does everyone think<br>
about removing the !AES128 ?<br>
Is anyone really afraid of AES128 being breakable, and AES256 still<br>
being secure?<br>
Can we add AES128 in again? I could not find any good reason against<br>
AES128 either, to me it seems that 128 bit psychologically seem less<br>
secure than 256 bit, but it depends on the kinds of ressources an<br>
attacker has, whether AES128 is more or less secure than AES256, and<br>
from my point of view, both algorithms are currently secure enough for<br>
practical use. (but either or even both could get broken tomorrow,<br>
theoretically)<br>
Hmmm ...<br>
Under the assumption that AES128 is currently secure:<br>
Since there are attacks against AES256, where AES256 is less secure than<br>
AES256, I think we the specifically should keep both AES128 and AES256<br>
in our ciphersuites, so that in the theoretical case that AES256 might<br>
get broken in an even more dramatic way, while AES128 might stay secure<br>
at the same time,<br>
we might want to be able to change to AES128 then. (algorithmic agility)<br>
If we now configure all clients and servers not to use AES128 anymore,<br>
then we will have hard time to turn off AES256 then, since we don´t have<br>
anything else left then. So from the algorithm-agility viewpoint, I vote<br>
for keeping both AES-128 and AES-256 in the ciphersuites, so that we<br>
have room for maneuver in the future.<br>
<br>
We not just have to think what is the best securest option now, we also<br>
have to think what we will need in the future.<br>
<div class="im"><br>
> And in addition, this change should be verified against <a href="http://ssllabs.com" target="_blank">ssllabs.com</a>.<br>
</div>One thing to keep in mind with verifying SRP is that servers normally<br>
should not advertise SRP unless it is actually configured on that<br>
server. So even if you remove the !SRP, it will most likely not change<br>
the cipher-suite options that are advertised.<br>
<div class="im"><br>
<br>
> So, Phillip, I reverted your commit temporarily with the intention to first re-discuss this before<br>
it finds its way into the final document, OK?<br>
</div>Sure, no problem.<br>
<div class="im"><br>
><br>
> No bad intention, but I feel this commit needs to be discussed first.<br>
> What do other people say about this commit?<br>
> Do you agree with that change in cipher string?<br>
><br>
><br>
> Don't worry, I will cherry pick from the other commits that you made<br>
(lots of good typo squatting changes etc) in the mean time. I mainly<br>
worry about the change in the cipher string.<br>
><br>
</div>Yes, feel free to cherry pick from my changes.<br>
<br>
<br>
Best regards,<br>
Philipp Gühring<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEUEARECAAYFAlKT388ACgkQlqQ+F+0wB3pauACdGv/uuGc4AIxnBQI0J/eJ2xBr<br>
JIAAlRz9LA3fmv4hmhOrl6kt294iQOk=<br>
=7tCS<br>
-----END PGP SIGNATURE-----<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>David DURVAUX
</div>