Aloha, Most vendors are still years away from being adequately prepared to receive and respond effectively to security vulnerabilities, and many don't have a clue how to react when somebody posts full disclosure to bugtraq. And it's not just vendors who need help and guidance; CERT and other security monitoring/advisory organizations have become at times a limiting factor in effective incident response, especially when the issue is truly critical calling into question the security integrity of billion-dollar commercial infrastructure around PKI. Take the Microsoft Windows certificate chain validation flaw for example. Basic constraints are ignored, enabling anyone with a valid certificate signed by a trusted CA to forge certificates that Windows automatically trusts. Millions of Windows computers are still vulnerable to this flaw, making SSL untrustworthy when Internet Explorer is used and making it possible to forge digital signatures on S/MIME e-mail messages. Instead of rallying behind awareness of the threat and its resolution, the whole issue was virtually ignored by CERT and other organizations that media rely on to separate hoaxes and fluff from really important security issues. It's likely that the muted response from official security alert groups, which in turn led to a muted response from the media, resulted from a desire to avoid giving any publicity or attention to the person who discovered the vulnerability and disclosed it on bugtraq without first notifying Microsoft and working through any responsible disclosure process. There is no better example of an incident that would have benefited from an accepted incident response procedure when a vulnerability is reported without responsible disclosure; or perhaps there is no better example of the uselessness of any such procedure and the absolute value of a self-informing infosec community that could care less whether the media and others who need guidance on reporting vulnerabilities in fact receive that guidance. Suppressing media attention that might gratify a malicious black-hat is the de facto incident response standard when responsible disclosure is ignored? Surely it's possible to separate the discovery from the discoverer -- if there were a replacement for christey-wysopal-vuln-disclosure that the IETF were ultimately to endorse that more completely spells out the roles and responsibilities, and the incident response plan, of everyone involved including the media it would be simple to communicate to reporters that "this vulnerability was discovered and published by a malicious person for the purpose of gang-style bragging rights, therefore we request that you leave out any mention of where knowledge of this threat came from and instead report the technical details that will help people protect themselves and their computers." Expiration of christey-wysopal-vuln-disclosure either leaves a void that needs to be filled by something more comprehensive and workable that takes into consideration the complexity of real-world incident response or it shows us that the social complexity and cost of responding to information security vulnerabilities exceeds by many factors the value it provides to anybody who is at-risk and only a few elite security researchers need be concerned with communicating about these matters while everyone else should just auto-update their OS and application software daily. Sincerely, Jason Coombs jasonc@science.org -- Robert Elz <kre@munnari.OZ.AU> writes: > That wasn't done here, so the "officially withdrawn it" really can only be > interpreted as "the authors are no longer pushing this doc". The authors stopped pushing this document _only in the IETF context_. However, the document is usually referenced by its http://www.ietf.org/ URL. I think that's why the situation is so confusing. On Mon, 23 Sep 2002, Florian Weimer wrote: > Date: Mon, 23 Sep 2002 20:01:11 +0200 > From: Florian Weimer <fw@deneb.enyo.de> > To: ietf@ietf.org > Subject: Status of draft-christey-wysopal-vuln-disclosure-00.txt > > At some point, the authors of this IETF draft have officially > withdrawn it, but this document is still being referenced a lot, > sometimes in contexts which might lead inexperienced readers to > believe that this draft is supported by the IETF. It's even expired. > > What's the status of the document, as far as the IETF is concerned? > Will it remain in the IETF archives forever? Has the withdrawal been > withdrawn?