On Wed, Feb 11, 2015 at 03:46:54PM +0000, Salz, Rich wrote:
> > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> > explicitly in DEFAULT) is a good one that maintains important backward
> > compatibility while providing the desired removal of RC4 by default. There's
> > no advantage to moving RC4 to LOW.
>
> Sure there is: it's an accurate description of the quality of protection provided by the algorithm. :)
Except that it is not. There are off-the-shelf key recovery attacks
on 56-bit DES (essentially the only LOW cipher anyone might actually
use, though nobody does anymore). The known attacks on RC4 are
only effective when a great many plaintexts includes the same
sensitive content at a fixed position in the data stream. While
this does mean we should stop using RC4 as soon as practical, it
is far from equating the security of RC4 with single-DES.
> It's also compatible with our documentation, which as was pointed
> out, always uses the word "currently" to describe the magic keywords.
Sure, there's some rope there, it does not mean we need to hang
ourselves. The basic ciphersuite primitives by now have well
understood meanings that should only be changed with great care if
at all.
> Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.
Except that "RC4" includes export-grade RC4, so that would be wrong.
Also Postfix defines a more usable user-interface of cipher "grades":
smtp_tls_cipher_grade = null | export | low | medium | high
where "export" is EXPORT and up, "low" is "LOW" and up, "medium"
is "MEDIUM" and up, with the underlying definitions also configurable
but most users are encouraged to stay well clear of those:
tls_null_cipherlist = eNULL:!aNULL
tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
instead users choose a grade, and may also specify exclusions:
smtp_tls_exclude_ciphers = RC4, PSK, aDSS, ...
this provides enough flexibility to allow emergency tweaks to be
applied by users to deal with future issues, without requiring
users to be experts in OpenSSL cipherlists.
It is important to remember that all the moving pieces are part of
an ecosystem:
* The OpenSSL project provides a foundation library to application
developers (like myself with Postfix) AND to O/S release
engineering teams that take upstream Postfix and upstream
OpenSSL and package these into integrated systems.
* The Postfix developers create a Postfix release with sensible
backwards-compatible and reasonably future-proof cipherlist
settings.
* Postfix is built from source by the O/S release engineering
team against some OpenSSL library available at the time of
the build.
* Users deploy systems with some Postfix version and some
OpenSSL version. They expect Postfix to be reasonably
interoperable and backwards-compatible out of the box.
I am not sympathetic to the view that libraries should set application
policy because application developers are lazy. I am not lazy,
and take the time to give users carefully chosen cipher settings.
These setting use documented primitives that avoid being too
specific, so that Postfix will take advantage of new ciphers (not
block progress) as these become available, and prioritizes these
appropriately.
If some developers do nothing and just want the library to be magic
security pixie-dust, then they benefit or get hurt by the "DEFAULT"
ciphersuite. If developers or users do make more fine-grained
choices, those ought not change capriciously.
--
Viktor.
