[Ach] One request on committing to the repository

Tue Nov 26 08:37:06 CET 2013

Hello,

Regarding AES, I would definitively remove the "!AES128".

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.
>
> 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-----
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>

-- 
David DURVAUX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20131126/48224a25/attachment.html>