I could certainly do a rfc3207bis document, or participate in a foo-over-tls omnibus. But, as Viktor points out, it's probably going to be a bit less self-congratulatory than we might have expected.
On Tue, Oct 22, 2013 at 9:46 AM, Stephen Farrell <[email protected]>wrote: > > 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
