Yep, that's a useful post - we shouldn't rush too much, but we do want to get things done so that developers and deployers have something to use.
I wonder what's the best way to proceed with this kind of stuff. I guess we want a BCP of some sort, but the question is how to handle the various different cases of foo-with-tls. - Yaron did a generic TLS BCP draft. [1] - PSA did an XMPP TLS BCP draft [2] - This sounds like we might want an SMTP TLS BCP draft or perhaps to add text to [3], but that's aiming for experimental and is just about using DANE. So at present we're heading towards a bunch of foo-with-tls BCPs. Could those usefully be merged or are they better kept separate? Thoughts? S. [1] https://tools.ietf.org/html/draft-sheffer-tls-bcp [2] https://tools.ietf.org/html/draft-saintandre-xmpp-tls [3] https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane On 10/22/2013 04: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. > > ==================== > > 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. > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
