[cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)

Nico Williams nico at cryptonector.com
Wed Jun 22 12:55:50 EDT 2011


On Wed, Jun 22, 2011 at 7:17 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Marsh Ray <marsh at extendedsubset.com> 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
--



More information about the cryptography mailing list