On Wed, Jun 22, 2011 at 7:17 AM, Peter Gutmann <[email protected]> wrote: > Marsh Ray <[email protected]> writes: >>Right, so one of the lessons learned here was that if IETF had considered >>APIs and not just protocols those bugs in TLS would have been found long ago. > > A pen-tester I know once found a (fairly serious) security hole under the > influence of (equally serious) pharmaceuticals, but I wouldn't recommend the > IETF adopting that as a design strategy, just as I'd be pretty terrified of > the result of the IETF trying to standardise a crypto API. If you look at the > history of all the widely-used crypto APIs: > > Crypto API designed by an individual or a single organisation: > > CryptoAPI: A handful of guys at Microsoft > PKCS #11: Someone at RSA (I've heard different stories). > JCE: A couple of guys at Sun. > OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim > Hudson. > > Crypto API designed by a committee: > > QED, I think.
I don't think you've demonstrated what you wanted to. Of your examples none were designed by any committees, and all had little or no open participation review by a large body of reviewers with diverse experiences. If anything you've demonstrated the opposite of what you thought you were demonstrating. Argument by ridicule does produce chuckles, but not necessarily good results. The IETF isn't a committee. If you think design by committee leads to failure (many of us do) and that the IETF means design-by-committee, then why does the IETF have any successes? The answer is probably not "luck" -- perhaps it's luck in the sense that by pure luck we got the right culture for success in spite of being a committee (but it's not), or perhaps the answer is that there are many more failures than successes at the IETF. But then, the IETF isn't a committee. I could go on and bore the list. We probably now have enough collective experience with crypto APIs that we could design one that doesn't suck. Yes, we could also design more sucky crypto APIs. And we do need crypto APIs. Someone is bound to try to fill that need. By your estimation no one person nor group can design a decent crypto API and we shouldn't try either. We know you're a master of ridicule, but leaving us with no choices is hardly helpful. Lastly, I'm not advocating APIs in all cases. I'm advocating *abstract* APIs for *protocols* and I have given strong circumstantial evidence that having such APIs is important, that not having them has caused real problems. That said, we have crypto APIs because we need them; if we want better ones I do think the IETF is best placed to produce them. Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
