# [Ach] One request on committing to the repository

Aaron Zauner azet at azet.org
Tue Nov 26 09:09:32 CET 2013

On 26 Nov 2013, at 08:37, David Durvaux <david.durvaux at gmail.com> wrote:

> Hello,
>
> Regarding AES, I would definitively remove the "!AES128”.
+1

we should also talk about the !SEED in there and why it’s there.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131126/a8e5442f/attachment.sig>