On 2/20/2014 2:14 PM, Troy Benjegerdes wrote: > On Mon, Feb 17, 2014 at 04:07:08PM -0800, Russ Allbery wrote: >> That's not out of the realm of possibility. We've collectively spent far >> more than that on the rxgk specification, although I suspect much of that >> time was uncompensated or written off as some variety of overhead by a lot >> of different institutions. > > I remember hearing lots of arguments that getting rid of DES keys would take > tens or hundreds of thousands of dollars, and that 'developers need to eat' > etc etc. > > Then one day an exploit was announced, and all of a sudden we got > http://www.openafs.org/pages/security/how-to-rekey.txt
There is a clearly a disconnect with how things work. A security issue is discovered. We don't announce it to the world until some manner of addressing it is in place. In this case close to nine months passed between notification of the vulnerability and the workaround was completed. Only then was a CVE filed, distributions notified, and finally a release issued. It is certainly true that once there was an exploitable vulnerability many individuals and their organizations prioritized getting a workaround in place when they would not have done so otherwise. That is the nature of security exploits or data corruption issues; they change the priority of the work. Often to the detriment of those doing the work because no one gets compensated for working on something you can't tell anyone about. Beyond that. When I and most others discuss getting rid of DES keys, we are not simply talking about the ability to configure your KDC to stop issuing DES keys as part of the afs service ticket. I am referring to halting the use of 56-bit keys for wire encryption. The workarounds for OPENAFS-SA-2013-003 do nothing to replace the 56-bit keys used by fcrypt for wire privacy and data integrity. > I need to eat too, but I'd rather focus on marketing and identifying who > exactly the customer base is that's going to pay for AFS file encryption, and > IPv6, and disconnected operation, and give them a free teaser of working > code than whining about how it's how hard to get the current customers to > buy stuff. You can't market something you don't have. Open source is not a free teaser. The Elders and Gatekeepers spent the better part of 2004 to 2007 trying to obtain funding for a road map better known as the wish list. The response from the community in no uncertain terms was "we cannot provide funding when there is no guarantee it will be completed." The response from large commercial operating system vendors that wanted to use the technology was that OpenAFS is too far from a first class file system to be given to end users as an alternative. The response from potential large new deployments was that there are too many performance warts; too many use cases that must be avoided; the security is too weak; the application compatibility is incomplete; and it is not used by enough other organizations. We all knew that; hence the existence of the unfunded wish list. I and others placed a bet that if we could build the product that we believe AFS should be that organizations would pay for it and we could recoup the development costs that way. We shall see if we were correct in the coming months. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
