[Ach] One request on committing to the repository

[Philipp Gühring]

Hi,

> This part of the cipher string is (as most of it) just c&p from Ivan
> Ristic's forward secrecy recommendation[1].

Ok, I will talk to Ivan directly as well.

> The only thing I noticed is that SRP is a SSLv3 (TLSv1.0?) only thing.

Where do you have that information from?

According to RFC 5054 ( http://tools.ietf.org/html/rfc5054 ), TLS-SRP
requires TLSEXT, 
which is not available in SSLv3, as far as I know, so this information
seems to be false.
According to http://tools.ietf.org/html/rfc4366 , TLSEXT is designed to be
backwards-compatible, so it applies to both TLS 1.0 and TLS1.1 (and
therefore also to TLS1.2)

As far as I can see
http://tools.ietf.org/html/rfc5054#section-2.8.1
is still compatible with http://www.rfc-editor.org/rfc/rfc6066.txt , so I
think it should work fine with TLSv1.2 too, but I have not tried it.

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

I am all for switching to TLSv1.2+, as fast as possible.
I don't think that SRP would not work with TLSv1.2+.
And I don't think that not writing !SRP would stop TLSv1.2 being used.
I just don't want to spread security recommendations that will break
future security enhancements.

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

I did not study that subject yet.
I think from the bitlength viewpoint, it should be similar to RSA, so I
would recommend 1024-2048 bits, but there are some limitations in some
crypto libraries, so we should take the best available.
Regeneration: How perfect do we want our forward-secrecy? 
My suggestion would be something like once-per-day to once-per-hour

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

I would say the non-ephemeral variant is unpractical, and I don't know
whether many CA's are actually issueing such certificates. The question
never popped up at CAcert as long as I have been involved, so either
OpenSSL issues them on request, or nobody ever tried and need one.
Additionall, it's not Perfect-Forward-Secrecy anymore, when you do
non-ephemeral. 
So from our point of view, I would say it's useless.


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

Yes, from the agility viewpoint, I totally agree. But with those ciphers,
I have not heard enough in public about them before, so I am not sure,
whether they were studied extensively enough so that we should recommend
them. If you know more about them and trust them, I don't mind adding them.


Best regards,
Philipp