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

[Adi Kriegisch]

Hi!

> > the Result is:
> > $ openssl ciphers -v
> > '-ALL:ECDH+aRSA+AES:DH+aRSA+AES:aRSA+kRSA+AES:+AES256' | cut -f1 -d" "
> > ECDHE-RSA-AES128-GCM-SHA256
> > ECDHE-RSA-AES128-SHA256
> > ECDHE-RSA-AES128-SHA
> > DHE-RSA-AES128-GCM-SHA256
> > DHE-RSA-AES128-SHA256
> > DHE-RSA-AES128-SHA
> > AES128-GCM-SHA256
> > AES128-SHA256
> > AES128-SHA
> > ECDHE-RSA-AES256-GCM-SHA384
> > ECDHE-RSA-AES256-SHA384
> > ECDHE-RSA-AES256-SHA
> > DHE-RSA-AES256-GCM-SHA384
> > DHE-RSA-AES256-SHA256
> > DHE-RSA-AES256-SHA
> > AES256-GCM-SHA384
> > AES256-SHA256
> > AES256-SHA
You do notice that you prefer non-ephemeral ciphers over ephemeral ones
here, right? As the fallback cipher you only ever need AES256-SHA and
nothing else to support legacy-old-really-old-legacy versions of openssl
at the very end of the cipher string.

Things with CipherB started getting messy when we added AES128 due to
sorting issues throughout all the different openssl versions.
As soon as Chacha20/Poly1305/ED25519 hits openssl in distros, we will need
to take a different road anyways.
Another design decision was the question whether to trust the NIST curves
or not. Sure, performance of ECDHE is better than that of DHE, but our
recommendations aren't directed to high traffic sites in the first place
but to small to medium sized networks who most probably won't see a
difference here. With ED25519 most probably entering TLSv<NEXT> that part
of the game changed, but we will still have to deal with it (ie choosing
only ed25519).

For reasons I do not completely understand, browser vendors do only
implement (or make available) certain TLS1.2 ciphers like
ECDHE-RSA-AES128-GCM-SHA256 but not their AES256 equivalent. The question
is how we want to deal with that in the future.

For now, getting CipherB as it is now consistent in the document should be
priority A; moving forward to either CipherB v2 or splitting distro support
by having CipherB-legacy and CipherB-current could be the way to go; but
this will require further discussion.

-- Adi
-------------- 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/20151108/729fa12b/attachment.sig>