[Ach] Adding more cipher suites

Aaron Zauner azet at azet.org
Fri Nov 15 03:15:23 CET 2013


What i actually meant was to add different AES128 ciphersuites (there are a lot of possibilities) not only as a fallback option. I do not see any reason to exclude AES128 from our paper and even the “harder” server configurations. 

Aaron (Greetings from Denver, CO)

On 14 Nov 2013, at 09:40, Adi Kriegisch <adi at kriegisch.at> wrote:

> Hi!
> 
>> It is my opinion that we should also add AES-128 and AES-192 based cipher suites as well as SHA256 for all of these (SHA256 is perfectly fine as far as i can tell). This sould also result in better browser support and support for java. AES-128 and AES-192 as well as SHA256 can be considered in the “strong” category in my opinion. This also doesn’t limit administrators as much. I just reviewed the paper a bit and noticed that we’re far too conservative with the amount of suites we recommend.  (See: Table 1, Table 2 in the DRAFT)
> Absolutely. There are two issues at the moment: The first, many of those
> ciphers and combinations aren't implemented in eg. OpenSSL and the second
> is that I did not find the time to review the iana listing[1] of all
> specified cipher suites and rebase our recommendations on those.
> Probably it is even time to add some notes about the upcoming TLSv1.3
> standard...
> 
> What is there in section 7.2 is all open for review and rewrite: I'd like
> to have sections there discussing key exchange mechanisms, authentication,
> ciphers and hash functions. Then briefly show how to map the admins
> preference to the standards[1]. And last (here starts the ugly part)
> compare that to reality: check which cipher suites are supported by which
> server operating systems and by which clients.
> When this section is done, I guess, our recommendation might change...
> 
>> There already has been discussion about adding AES128, but nobody acutally did. We should also speak about including SHA512 with some recommendations and configurations.
> Yeah, the main motivation behind AES128 support was supporting Java7. The
> reason AES128 vanished from the proposal was that Java[67] only supports DH
> params up to 1024bit which we agreed wasn't enough. At the moment the
> suggestion is to use DH params >2048 (greater than the bitlength of the
> corresponding RSA key).
> 
> What do you think?
> 
> -- Adi
> 
> [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131115/0e51ac37/attachment.sig>


More information about the Ach mailing list