[Ach] One request on committing to the repository

[Adi Kriegisch]

Hi!

> > (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?
No, I don't. Thank you for looking at it and providing the above reasoning.
This part of the cipher string is (as most of it) just c&p from Ivan
Ristic's forward secrecy recommendation[1].
The only thing I noticed is that SRP is a SSLv3 (TLSv1.0?) only thing. We
probably should not put too much effort into this as one of our main
suggestions is to switch to TLSv1.2+ as fast as possible.

> While we are at changing the ciphersuites: What does everyone think
> about removing the !AES128 ?
Absolutely. Please pick all your favorite cipher suites from the IANA page
and send a list in the preferred order. Then we'll just create a new cipher
string and we finally have a recommendation.
btw. what is your recommendation for Diffie-Hellman parameter size and how
often should they be regenerated?

> 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)
To me this is (close to) impossible to decide. The ENISA paper[2] lists two
different numbers on that:
* page 21 says AES-128 provides 85 bits of security (given 2^43 encryptions
  with different keys of the same plain text)
* page 23 lists a related key attack for AES256 for which AES128 isn't
  susceptible.
* page 24 says AES128 provides 126.2bits of security (AES256 gives 254.4)

Depending on the context the cipher is used some attacks might be
infeasible while new ones may arise. What would be great is to get a
cryptographer's view on that in the context of our (planned)
recommendations: ephemeral DH/ECDH for TLS (and probably a comment on the
non-ephemeral variant).

> we might want to be able to change to AES128 then. (algorithmic agility)
"algorithmic agility" -- a gread word btw. +1 from me. In that sense there
should be CAMELLIA in there too. Does anyone know about ARIA?

-- Adi

[1] http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
[2] http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20131126/466b80f0/attachment.sig>