[Ach] Vote for new Cipherstring B [Was: Issue with OpenSSL >0.9.8l]

[Torsten Gigler]

Hi,

may I suggest to write a policy how to setup the cipher string and the
order of its ciphers.
>From the most important to the less important rule (e.g. like from Perfect
Secrecy ... Bit len of the Hash).

I see, that it may take a while to change chipher strings, if you maintain
a lot of systems. So I'd prefer to include reliable ciphers that are
planned for future use, even if they are not or rarely supported by
browsers today (e.g. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384).

Perhaps it could be an idea to have a 'CipherString C' for latency Servers.
Perhaps there you could place ECDHE with higher priority than DHE, and
AES-256 higher than AES-128.

... only my 2 cents...

Kind regards
Torsten


2014-06-04 15:24 GMT+02:00 Aaron Zauner <azet at azet.org>:

> Hi Philip,
>
> Philipp Gühring wrote:
> > Hi,
> >
> > I dont't mind dropping *256, but I currently believe that SHA384 is the
> > only secure hash in the SHA2 family, all other hashes leak their
> > complete internal state. Length-Extension-Attack...
> > From security point of view, I would drop SHA2-256 and SHA2-512, and
> > promote SHA2-384.
> > But I do not know what that means interoperability-wise.
>
> There is no support for SHA384 with 128 bit symmetric ciphers in TLS:
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
>
> So,.. keeping them is completely useless if we drop *256.
>
>
> Aaron
>
>
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140604/0ed8aec2/attachment.html>