In the aftermath of the Snowden revelations on Project Bullrun and the SIGINT Enabling Project, NIST is reviewing its procedures of how cryptographic standards should be developed. It is a laudable development to have the procedures publicly discussed and to request feedback on them. The cryptographic competitions organized by NIST were also laudable efforts to involve the cryptographic community at large.
However, most of the document describes essentially the status quo -- how are standards developed presently and in the past -- and does not state anywhere that a change of procedure is needed; unless, of course, this description is presenting what will happen in the bright and glorious future and is a departure from what was there before. To clarify that change is coming, and I do hope that this time change is coming, it is necessary to highlight where the future procedures will be different from current and past procedures and how the future procedures will prevent targeted influencing of standards by government agencies. This should happen as part of this document (or as a separate report, to be released at the same time) detailing the vulnerabilities of the old system. Obviously these considerations of how the new system improves on the old should include the threat of subversion by the agencies but also the problem of companies pushing modifications that give them IPR related benefits (the case of the Certicom patent on alternative points for Dual_EC comes to mind, here).
As a researcher in cryptography I could not imagine that NIST had not dropped support for Dual_EC back in 2007, but I have to admit that I failed to check. I think that for security standards the comments phase should never end -- NIST should always be open for comments showing vulnerabilities in their published standards and commit to reacting to such comments publicly. I, like many others, misinterpreted the silence after the back door announcement and widespread publication (e.g. by Schneier in WIRED) as a sign that this problem was dealt with and the RNG was no longer supported. A look on http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html shows how wrong I was. How could this happen? What are the lessons for the future to prevent repetition? Since this document is a meta-standard on how to make standards a reflection on what went wrong in the past is important.
Instead of promising change, the current document praises NSA's work in the "Stakeholders" part and says "NIST works closely with the NSA in the development of cryptographic standards. This is done because of the NSA's vast expertise in cryptography and because NIST, under the Federal Information Security Management Act of 2002, is statutorily required to consult with the NSA on standards." After this statement I would like to see a clear explanation that NIST is emancipating itself and that in the future the collaboration will be restricted to 'consulting with the NSA' rather than 'taking input from the NSA without requiring additional evaluation.' Is there a memorandum of understanding (similar to the one in http://epic.org/crypto/dss/nsa_abernathy_letter.html) accompanying the Federal Information Security Management Act? Are there agreements between NIST and the NSA beyond this?
The "Stakeholders" part is an example of the huge influence that NIST's recommendations enjoy, but with great power comes great responsibility. This power is also a weakness of the system: if a target of the agencies is likely to adopt a NIST standard, the standard becomes a valuable target for sabotage and NIST needs to be aware of this and should demonstrate awareness as part of this document.
I am sympathetic to the feelings of NIST employees that they had not expected the NSA to deal with them in the way revealed on 5 September 2013, however, in historic perspective, SP800-90 (and whatever else further research will find) are just some more recent examples of a collaboration between two unequal partners. This case too closely mirrors the comments reported in the "New NIST/NSA Revelations" from May 1993 (!) (see e.g. http://epic.org/crypto/dss/new_nist_nsa_revelations.html) 'the "NSA problem" was apparently the intelligence agency's demand that perceived "national security" considerations take precedence in the development of the DSS. From the outset, NSA cloaked the deliberations in secrecy.' (and other reports of tension between NIST and the NSA stated in that report). There are further parallels between the DSS case and the SP800-90 case: in both cases the public was left in the dark about the provenance of the algorithms, in both cases the public perception was that the algorithms were developed by NIST, while in fact they were developed by the NSA.
It is important that future standardization efforts correctly attribute authorship of algorithms and other inputs. This is already the case for input from the academic community and to some extent also for input from security researchers and companies but not at all the case for input from government agencies. Some standards, including SP800-90, include acknowledgments to NSA employees (mentioned by name), but there is no indication of their role in the standard and it is unclear whether they were the only NSA employees involved.
If changes to a standard become necessary, the change log should include acknowledgments and justifications for the changes. See https://projectbullrun.org/dual-ec/standard-change.html for reasons.
I recommend to amend the section on "Transparency" to expand "and provenance of proposed standards or guidelines" to "and provenance of proposed standards, guidelines, and input on drafts and standards, by giving names and affiliations".
I recommend to amend the section "Openness" by including as a final sentence "All inputs received will be made available publicly, this includes, but is not limited to, the initial draft including references for design and analysis of the included components, all comments received in public and internal consultations, presentations at workshops, etc." I understand that certain provisions need to be made for companies reporting on IPR, but I would like to have these to be as public as possible; this is a must if they are instrumental in making choices. As the bare minimum there should be a time limit on how long such comments can remain private.
I would like to see a clear mission statement that NIST's mission is to achieve security, which includes security against attackers inside the security agencies. Cases such as the DSS where even the public announcement included "Among the factors that were considered during this process were [..] impact on national security and law enforcement" should be a thing of the past. This should also be reflected in the paragraph titled "Balance".
There are several other things in the draft that should change before adoption:
l.46 New paragraph before "Continuous Improvement:"; there were also some missing spaces in the text.
l.46 The text on "Continuous Improvement:" should include mechanisms how NIST reacts to vulnerabilities discovered after a standard has been adopted. This should include a commmitment to address the concerns publicly.
l.50 I hope that also the government agencies are encouraged to identify weaknesses and inform the public and NIST about them.
l.60-67 This is backwards for the part on elliptic curves included in Suite B. NIST received them from the NSA and then some of them were included in Suite B. This is an appropriate place to clarify this. It is public knowledge and has not been denied but it is not on public record and the presentation given here distorts the facts.
l.218 The randomness beacon should not be used for generating cryptographic key material, as correctly stated on that site; so why is it included here? To the very least include "for testing purposes" in the description.
l.283 Is this the correct story? This is the version you will be held accountable for. Was it NIST to take initiative, as claimed in "NIST recognized", or the community or the NSA?
l.295 Who provided this document to ISO? NIST or ANSI?
l.308/309 The inclusion of Hash_DRBG is inadequately explained; whose request was this?
l.315/316 "All such feedback was considered for incorporation into the SP 800-90 documents." is disgraceful to those who were told that their comments were too late since the standard had already been implemented by companies.
I'm happy to see that NIST has recently published some more public comments but this still does not seem to cover all comments made regarding SP800-90 in general, and Dual_EC in particular.
l.317-319 "Some in the cryptographic community have expressed concern": This does not report the facts correctly. Several in the cryptographic community have expressed concern about the security since the very first draft of SP800-90 back in 2004; the potential back door was widely publicized in 2007. At that point NIST should have dropped support for Dual_EC; dropping it in September 2013 is better than never but significantly too late.
It is unclear to the public at which point NIST became aware of the possibility of a back door in Dual EC; Certicom filed for a patent on using this back door in January 2005; did they inform NIST at that point? There are stories that the potential back door was discussed at meetings before summer 2007 and that the possibility was discarded -- when was this and who deserves credit for finding that Dual_EC is backdoorable and what arguments were used to ignore it? We need to understand the history to avoid a repetition of this!