Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

"Jason Coombs" <jasonc@science.org> Mon, 23 December 2002 16:46 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08853; Mon, 23 Dec 2002 11:46:14 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QVjP-0002Wr-00 for ietf-list@ran.ietf.org; Mon, 23 Dec 2002 11:47:07 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QFWQ-0008R9-00 for ietf@ran.ietf.org; Sun, 22 Dec 2002 18:28:38 -0500
Received: from mail.digitalmarketplace.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07033 for <ietf@ietf.org>; Sun, 22 Dec 2002 18:24:03 -0500 (EST)
Received: from win2kdev ([208.3.65.168]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Sun, 22 Dec 2002 15:52:26 -0800
Reply-To: jasonc@science.org
From: Jason Coombs <jasonc@science.org>
To: cwysopal@atstake.com, coley@mitre.org
Cc: fw@deneb.enyo.de, dee3@torque.pothole.com, ietf@ietf.org, kre@munnari.OZ.AU, cert@cert.org, info@knowngoods.org, secure@microsoft.com, Bruce Schneier <schneier@counterpane.com>
Subject: Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt
Date: Sun, 22 Dec 2002 13:28:15 -1000
Message-ID: <ILEPILDHBOLAHHEIMALBOEOCEGAA.jasonc@science.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

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?