On 10/22/2013 05:26 PM, Paul Hoffman wrote:
This was posted last night by Viktor Dukhovni on the cryptography mailing list, but is certainly applicable here. Forwarded with Viktor's permission.
Very good post - although the main problem seems to be fallback to cleartext in SMTP due to lack of co-ordination, not attempting better support of crypto. Although this has historically not been the case, perhaps users may start wanting draconian error-handling as regards encrypted email between the client and server as a default. IMHO that is the only factor that could force co-ordination of better support of larger keys in the client and ECC curves. Obviously, this option already exists in most mail clients - yet users are typically unaware of the distinction (and the confusing terminological history re enforcement of TLS and StarTLS upgrading). While perhaps more draconian error-handling would help in standards rather than assuming cleartext fallback, it seems the real failure here is a usability issue with many mail clients where users are unaware their mail is being sent in the clear.
Right now, at least on Linux, Mozilla has effectively it seems stopped development on Thunderbird (truly a shame) so there's virtually no usable email clients. Are folks aware of any that make "forcing TLS encryption" both the default and offer severe warnings if it fails?
==================== 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 <http://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 serverssupport 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. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
