[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”.

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>
>> 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
>>> +  SSLCipherSuite
>>> \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.
>> We had a discussion about SRP 2 weeks ago here:
>> 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.
>>> What do other people say about this commit?
>>> 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
>> 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
> -- 
> _______________________________________________
> 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>

More information about the Ach mailing list