On Sat, Oct 19, 2013 at 11:46 AM, Stephen Farrell <[email protected] > wrote:
> > Hiya, > > FWIW, I don't buy Phill's theory at all. > We have a document that states there is a $250 million budget set for a program that includes infiltrating the standards process as a stated part of the program. Now we can dispute the authenticity of the document but I see it as confirming my earlier strong suspicion. > On the specific topics below, if I recall correctly, both > were uncontroversial parts of the "design" of PKI for years > before they became problematic for the web PKI when it > finally started to seriously consider revocation. They were uncontroversial until the DigiNotar and Flame incidents and until the EFF certificate observatory started a FUD attack making spurious claims . Until that point I was mainly concerned with the risk that one of my CAs might be breached. I did not see the need for Name constraints because I had other controls that I consider to be sufficient. The OCSP feature was very controversial at the time the limitation was originally introduced. The reason I did not press the issue then was that I did not see it as critical and insisting on a strong status result could arguably be seen as interfering with the Valicert business model at the time. > And it > seems to me that both "sides" in that debate were inflexible > and unwilling to make changes. I still don't know why that > was, and it still seems dumb to me, but life's full of little > mysteries like that. > My position is based on the actions taken by the deployed base. I can't change that and so I don't have much ability to change my position. I can't see why the inability of the DoD to support an accurate status result should require the rest of us to adopt their lowest common denominator security. > And I am just not seeing how this is related to pervasive > monitoring except very very tangentially - Phill, can you > please explain its relevance? > I believe that the vulnerability exploited in Flame would have been closed had the standards changes resisted by the DoD been adopted in a timely fashion and that the DigiNotar incident might have been detected earlier. The documentary evidence shows that interfering with the standards process to prevent deployment of countermeasures is part of the cost of running PRISM etc. That is a cost that I am not prepared to pay because these generals who I have to sit in rooms with and listen to their plans for cyber-attack are making use less safe by compromising our ability to achieve strong cyber-defense. The question of how we can build open standards to defend against covert pervasive monitoring in the face of attempts to disrupt these efforts is a very difficult one. > And finally the subject line also seems unwise as it'll probably > just annoy folks and just distract us from getting real work > done. (So, if it does annoy you, please try be moderate in > your response, or maybe don't even send that mail, until we > see how Phill justifies its relevance.) > Well we could spend the next few years dancing round the subject and pretending that the elephants are not in the room but I have no intention of doing so. Now that my question on Alexander has been answered, I am looking for an answer to the question I raised at the RSA conference this year: How can we have a government-industry partnership to improve cyber security when a part of the military is actively engaged in subverting the standards process to protect vulnerabilities they might use in attacks? This is not the only forum I am raising this question, I am raising it with the policy makers in government as well. I am quite used to being accused of peddling an agenda. For some reasons CAs are always accused of having some covert agenda and raising this on the lists is never seen as objectionable because it is so frequent. But the response I give is not 'how dare you ask that question' but instead 'why don't you hold all the other parties you rely on to the same degree of scrutiny'. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
