On 11/19/2015 12:28 PM, Viktor Dukhovni wrote: > What algorithms people use on > their own data is their choice and risk decision not ours.
I heartily agree with the sentiment. A low- or mid-level library is not the right place to be making and enshrining policy decisions. We can take yet another step in the same direction. There are several job descriptions: 1) Writing the library code. 2) Compiling the library code. This might be done by some distributor. This is where final decisions about #define options are made. 3) Linking against the compiled library and running the application. 4) Running the counterpart application on the other end of the communication line. You would think that the guy in job #3 would be in the best position to make policy decisions ... but sometimes even he doesn't get to make that decision, because of #4. It takes two to tango. It seems very likely that some people are using openssl to communicate with legacy devices that use "outdated" crypto primitives. -- There are /some/ cases where it is better to communicate in the clear than to encrypt badly. -- There are /some/ cases where it is better to not communicate at all than to encrypt badly. ++ Sometimes not! There is no such thing as absolute security, and sometimes an algorithm that would not withstand an "advanced persistent" attack might be good enough for some quick-and-dirty tactical purpose. To say the same thing another way: I am quite sure that many /persons/ on this list, if assigned to job #3 and/or job #4, could make wise decisions at those levels, based on information available at those levels. Indeed there are some persons on this list who wear all four hats simultaneously. So the question is, are there any representatives of category #3 who are willing to speak on behalf of /everybody/ in that category? If not, it seems this thread is asking a question that cannot be answered. To say the same thing yet another way, fundamentally we have a communication problem, or rather two separate communication problems: A) The experts on this list know that certain crypto primitives are "broken or outdated". This needs to be communicated to the people who are actually in a position to make and implement policy. B) There is some question as to whether users in the field have received message (A) and successfully ended all use of the deprecated primitives. It would be nice if the people who know the status could communicate this back to the developers. The problem is: It's not obvious that discussions on this list will solve either of these communication problems. It's very asymmetrical: If somebody squawks, you know you have a problem ... but the converse does not hold. Furthermore, it seems likely that the people who subscribe to this list have long since gotten message (A) ... but what about non-subscribers? There's a correlation there, the sort of correlation that makes it very perilous to extrapolate. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
