Transparency in Specifications and PRISM-class attacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



One of the biggest problems resulting from the Snowden/PRISM fiasco is that we now know that the NSA has been spending a significant sum (part but not all of a $250 million budget) on infiltrating and manipulating the standards process.

As one of my friends in the civil rights movement from the 60s told me, the worst thing that we could do now is to have a witch hunt looking for the informers. Not least because it is not just the NSA that we should worry about. There are many other governments attempting to influence decisions in standards process for their own ends.

For what it is worth, I think the mode of influence is likely indirect. If anyone has seen the movie Breaking Glass, there is the scene where the record company A&R man tells the manager to stand firm against the band member's demand for a new rig that he tells the band that their sound desperately needs.

The issue is not limited to pure security issues either. The biggest diplomatic storms over the Internet come from the perception that the US is controlling IP address space and BGP AS numbers. The risk for a foreign government is that the US could abuse its influence over the institutions it has created to manage these resources for economic leverage at some point.


The issue we need to focus on is how to convince our audience that our specifications have not been compromised by government influence. 

Whatever our personal political views on the matter are, the views of our audience are likely to be different. Most of our audience are not US citizens, they are not even from the Anglosphere.

Ever since I left MIT to help start VeriSign I have been on notice that every proposal I make is immediately suspect as it might be an attempt to bind the Internet to the power of the one CA. That is OK, I don't complaint about that, I have always understood that anyone who is taking on a position of extreme responsibility is subject to an equally extreme degree of proof.

The point I am making here is everyone else needs to think in the same manner. 


One bad habit I think that should stop is trimming requirements before starting design. If a legitimate use case raises a legitimate requirement, that requirement should appear in the final requirements document produced whether it is addressed in the final design or not.

The process I have seen instead is that people argue about whether a requirement should be included in the requirements document and the final requirements document is a list of requirements the noisiest people in the group thought were important rather than what the document should be which is a tool to determine whether the design is capable of addressing the use cases.


And yes, I am raising this because I suspect that manipulating requirements is one of the chief ways that undue and corrupt influence is applied. 

--
Website: http://hallambaker.com/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]