Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts

[Peter Gutmann <[e-mail]>]

Tony Arcieri <[e-mail]> writes:

>"Phillip Rogaway offers a royalty-free non-exclusive license to all claims of
>the referenced patents needed to realize a fully compliant implementation of
>any IETF standards-track protocol supporting AES-OCB (RFC 7253)."

That's still not going to work, for two reasons.  This first is that it
misunderstands how an implementation of, say, TLS works.  Virtually all TLS
implementations aren't a monolithic TLS-only code block but are built on top
of a general-purpose crypto library, for Windows CryptoAPI, for everything
else OpenSSL, Crypto++, mbedTLS, PKCS #11, my own cryptlib, etc. Taking the
vendor-neutral PKCS #11 as an example, what the above is requiring is an
implementation of Maxwell's demon in software, that a PKCS #11 library be able
to tell whether the handle from C_CreateObject( &handle, { CKA_KEY_TYPE, key,
CKK_AES_OCB } ) will be used to encrypt TLS data (OK) or non-TLS data (not
OK).

The second is legal.  Any commercial user of whatever the crypto library is is
going to get their lawyers to look at that requirement and have a fit, not
even because of the above very technical problem but just from the knowledge
that they'll be running code that, at the slightest glitch, will potentially
expose them to a patent lawsuit.  I've seen companies spend 1-2 years debating
whether using generic permissive BSD-licensed code is safe, and now they'll be
asked to decide whether the risk in the above is worthwhile because blah blah
geekspeak geekspeak, for which the answer will most likely be "no".

I'd love to use OCB, it's a really nice, elegant mode, but unfortunately
unless the usage conditions are "freely available without restrictions" I
can't.  And that's not from rabid freetardism, it's from pragmatism, it's too
risky legally.

Peter.