Re: Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement

Jay Daley <jay@ietf.org> Wed, 05 August 2020 22:11 UTC

Return-Path: <jay@ietf.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68503A046E for <ietf@ietfa.amsl.com>; Wed, 5 Aug 2020 15:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ud9amMhY9CH; Wed, 5 Aug 2020 15:11:10 -0700 (PDT)
Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 41B5F3A0474; Wed, 5 Aug 2020 15:11:10 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement
From: Jay Daley <jay@ietf.org>
In-Reply-To: <m2tuxgn8pu.wl-randy@psg.com>
Date: Thu, 06 Aug 2020 10:11:08 +1200
Cc: IETF Discussion List <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5DCEBC2-3585-4E0A-9415-9695AD11B914@ietf.org>
References: <159651200228.24262.1827308624474280314@ietfa.amsl.com> <m2k0yeca1a.wl-randy@psg.com> <793241C9-C75C-407D-AD98-06E13C789154@ietf.org> <m28seuc4po.wl-randy@psg.com> <DCA840AE-5620-40E7-AD24-E1CC0C7BF8C7@ietf.org> <m2tuxgn8pu.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mAFVrkT4xY0z1mbUa8qgX-3gLeQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 22:11:12 -0000


> On 6/08/2020, at 8:22 AM, Randy Bush <randy@psg.com> wrote:
> 
> i had planned to drop the thread, but mirja beat me up for being
> obscure.  so my apologies for trying again.
> 
> first, i am an amateur here.  i do some opsec, have taught, but am not
> an expert.  which is why i passed it to a friend with deeper expertise.
> 
> embargo periods seem to vary.  but my amateur observation is that the
> mode seems to be 90 days.  as long as it is not ridiculous, i would
> prefer not to have a dog in this fight.

As noted twice now, adding a deadline is reasonable as is 90 days for that deadline and that has already been included in the latest update.

> 
> but the issue my friend raised which concerns me more is adding more a
> restrictive "Limitations" section than already covered by law and custom.
> i am a researcher.  i have dabbled in opsec research, and conducted
> attacks on the live global internet for that purpose, e.g. see [0].
> real researchers act responsibly.  attackers do not.  do not deter and
> further complicate the lives of the researchers who are trying to help
> you deter the attackers.
> 
> the ietf is not a special snowflake, just a noisy one.

Indeed and this proposed policy is in no way a special snowflake policy.  

Please remember that the limitations section goes hand-in-hand with the commitment not to take legal action against those that follow the policy.  Without the former the latter is not possible and the latter is regarded as important by security researchers.

Here are just two examples of suspiciously similar looking policies replete with both limitations and a commitment regarding legal action:

	https://trust.salesforce.com/en/security/responsible-disclosure-policy/
	https://www.okta.com/vulnerability-reporting-policy/

To understand just how common it is to have these limitations you can take this one: 

	"Accessing, or attempting to access, data or information that you are not authorised to access"

and use the original version before our slight amendment

	"Accessing, or attempting to access, data or information that does not belong to you"

and do a web search for that, which should provide sufficient evidence that this is not overly invented.


BTW When I told you earlier that the sec ADs had reviewed this I was only partially correct, one did but not the other.  Apologies for that.

Jay


> 
> randy
> 
> 
> [0] - https://archive.psg.com/181101.imc-communities.pdf
> 

-- 
Jay Daley
IETF Executive Director
jay@ietf.org