[Ach] Cipher-Order: AES128/AES256 - was: Secure E-Mail Transport based on DNSSec/TLSA/DANE

[Torsten Gigler]

Hi,

I'd like to suggest to discuss about the policy of selecting the ciphers and bringing them into a
proposed order, when discussing about a new cipher string.
This is about like Gunnar wrote today. The String building is a different issue...

Well, my favorite 2 cents about the policy could be found here:
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Server_Protocol_and_Cipher_Configuration
E.g. I'd favor GCM over CBC regardless of the cipher size (of the same algorithm). Additionally I'd
suggest to see the consequences using different clients. There is a simulation with various browsers
on slide nr #10:
https://www.owasp.org/images/1/19/Richtig_verschluesseln_mit_SSL%2BTLS_-_Achim_Hoffmann%2BTorsten_Gigler.pdf
from last year.
There are different ways to prioritize different points of the list, and the solution is always a
compromise these days. So changing some order in prioritizing parts of the algorithms may have huge
consequences to the order of the cipher string. All together, I think it gets more clear to discuss
about the rules for the policy first... 

This all may be extended regarding (MX-)SMTP and transport layer encryption. Some people bring
forward the point that most encryption works there 'on best effort' mode, so a legacy encryption is
claimed to be better than none..
Well I'd not go so far, I'd never recommend to use broken encryption techniques, but this Cipher
String may be more compatible to legacy algorithms than e.g. the one for https... 
[Note: In my opinion Transport Layer Protection of SMTP should be revised in general, e.g a user
should be able to signal to abstain from delivering a mail, if not (at least) the transport is
protected]
 
Kind regards
Torsten

Am 08.11.2015 um 15:13 schrieb Gunnar Haslinger:
> let me sum up which requirements we considered so far:
>
> Which Ciphers should be included:
> 1. start with the Ciphers included in the Current CipherString-B, they
> are still sane
> 2. Camellia could be considered to be removed.
> 3. additional Ciphers could be include if they are sane
> 4. Ciphers which seem to be unnecessary (e.g. ECDHE with SHA1, Clients
> capable ECDH are all capable SHA2) could be removed
>
> Which Ciphers should be preferred:
> 5. Choose a PFS Cipher if Client/Server are able to
> 6. Prefer a modern GCM/SHA2 to SHA1
> 7. Performance: ECDHE could be prefered over DHE
> 8. Performance: AES128 could be prefered over AES256
>
> How should the String-Building be done:
> 9. deactivating Ciphers in OpenSSL gives not predictable results in
> newer versions as newer ciphers will be added
> 10. Sorting by "+...." has to be done the least significant property
> first and the most significant property last
> 11. Keep the String short, simple, self-explaining, logical
> 12. Do not include unwanted Buzzwords like "+SSLv3"