Viktor Dukhovni | 22 Oct 06:50 2013

Hasty PRISM proofing considered harmful

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
	  and other sites have "stronger" security by switching to

	  # 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

	* 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 unchartered 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.


The cryptography mailing list
cryptography <at>