This was posted last night by Viktor Dukhovni on the cryptography mailing
list, but is certainly applicable here. Forwarded with Viktor's permission.

====================

There have been many recent efforts to harden the cryptographic
security of various systems.  I would like to urge anyone considering
taking steps in that direction to exercise due caution.

Multiple recent attempts at improvement backfire in various ways:

   - RedHat has been under pressure for some time to enable EC support
     in their OpenSSL RPM package.

    * They finally relented and added EC support ~1 week ago.  However,
      they quickly decided to play it safe and enable just the Suite-B
      curves: secp256r1, secp384r1 and no others.

    * They neglected to consider that the new libraries now
      happily negotiate EECDH key exchange TLS cipher-suites with
      servers that typically don't know of (or can't act on) the
      client's limitations.

    * At the same time newly hardened SMTP servers at gmx.de
      and other sites have "stronger" security by switching to
      secp521r1.

      # Result: SMTP TLS handshakes break, and more mail goes out in
        the clear!

      # With TLS, no EC is better than crippled EC.

   - GnuTLS sets aggressive client-side EDH prime-size lower bound.

    * Exim encounters interoperability problems and works-around
      the setting by allowing 1024-bit EDH in SMTP clients while
      using 2048-bit EDH in the server (which generally works for
      SMTP).

    * Debian decides to improve security in Exim and raises this
      to 2048-bits, breaking interoperability again.

       # Result:  Since SMTP TLS is generally opportunistic, when
         TLS handshakes break, more mail is transmitted in the clear!

   - Some email administrators disable RC4 (enable only the OpenSSL "HIGH"
     ciphers) in opportunistic TLS.  Many extant Microsoft Exchange servers
     support only RC4-SHA1, RC4-MD5 and 3DES (whose implementation is
     breaks post handshake in data transfer).

       # Result: TLS handshakes fail, and mail is sent in the clear.

   - There's lots of press about CRIME, BEAST, ... and some SMTP
     administrators configure their systems to prefer RC4 and
     avoid CBC ciphersuites.

    # The attacks in question are primarily HTTPS attacks,
    cryptanalysis of RC4 may well be the greater threat to SMTP.

There are I expect similar examples of good intentions, but poor
outcomes outside the world of SMTP.  Raising the bar on Internet
security will take considerable time and effort.  Updated standards
will have to be developed, toolkits extended to support them and
applications updated.  Rolling improved security out to end-users
will likely take on the order of a decade.

In the mean-time, users should make an effort to configure their
systems to employ current best-practice security, trying to go
beyond that into uncharted territory may well be counter-productive.

Endpoint security and misuse of data at rest are still IMHO the
bigger issues.  I am much more concerned about the proliferation
of miniature programmable computers inside our computers (CPUs and
programmable firmware in disk controllers, battery controllers,
BMC controllers, with opaque binary firmware update blobs, and
complex supply chains) that about secp256r1 vs secp521r1.

We thought embedded devices were for physical infrastructure
engineers to worry about, but now they are proliferating inside
our general purpose computers.  The next Stuxnet will run on one
of the invisible computers inside your computer.

With concerted effort we can improve the crypto protocols, but will
it matter if the architecture on top of which the crypto runs has
an ever growing attack surface.