[Ach] One request on committing to the repository

[Philipp Gühring]

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

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
-----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-----