RE: "Recommended" is a bad word :)

So over the last couple of days I spent some quality time reading http://eprint.iacr.org/2014/206 - it’s another great example of the challenges with composing secure primitives even in the simplest of ways. Given the existence of such deep issues, listing some known bad algorithms feels like barely scratching the surface of the problem. At the same time, there remain a large number of ways to design secure schemes using existing cryptographic primitives, and the API does not wish to obstruct that in any way.

So here’s a concrete proposal: would it address the objections if we replaced this text in Section 18:

As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations.

However, in order to promote interoperability for developers, there are a number of recommended algorithms. The recommended algorithms are:
With the following text:

As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations. As highlighted in Section 5, even strong cryptographic algorithms may be combined in insecure ways. Users should therefore proceed with extreme caution when inventing new cryptographic protocols.

Implementers should carefully review their support for different algorithms based on the evolving state of the cryptographic literature. It is expected that the set of widely-accepted algorithms will change over time as new advances are made.

With  the above caveats in mind, in order to promote interoperability for developers, this specification includes a list of suggested algorithms. These are considered to be the most widely used algorithms in practice at the time of writing, and therefore provide a good starting point for initial implementations of this specification. The suggested algorithms are:


From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Tuesday, May 13, 2014 8:11 AM
To: Salz, Rich
Cc: Vijay Bharadwaj; public-webcrypto-comments@w3.org
Subject: Re: "Recommended" is a bad word :)

Rich,

I was looking for some middle ground between your proposal and Ryan's rather strongly-worded objections. An "example" is by definition just one item taken from a larger list, so there is no danger of a list of examples being taken as exhaustive.

I personally think Ryan's concerns are perhaps a little overstated, so that is why I was wondering aloud about middle ground.

...Mark

On Tue, May 13, 2014 at 8:00 AM, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:
> Would it help to augment the existing warning text cited by Vijay with some _examples_ of published attacks / weaknesses for some of the algorithms ?

How does that not run into the same concern about being taken as a comprehensive warning?  Is “For example, …” considered that much less compelling? As for examples, just read the titles in the proposed security references section.

> IIUC the concern with the proposed text is that it might give the impression we're providing exhaustive, up-to-date advice and that we have some agreed yardstick by which to measure whether a given algorithm should get a thumbs up or thumbs down.

There will never be exhaustive, up-to-date advice. Given that truism, what do you do?  That’s a real question. And as for the yardstick, you’ve got a list of open references, and the original CFRG/Paterson et al email message gave a summary.
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me<mailto:rsalz@jabber.me>; Twitter: RichSalz