Re: Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement

Jay Daley <jay@ietf.org> Tue, 04 August 2020 23:16 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 7385F3A111B for <ietf@ietfa.amsl.com>; Tue, 4 Aug 2020 16:16:28 -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 AZB7DxKdtB3c; Tue, 4 Aug 2020 16:16:27 -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 A06893A1119; Tue, 4 Aug 2020 16:16:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
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: <m2k0yeca1a.wl-randy@psg.com>
Date: Wed, 05 Aug 2020 11:16:24 +1200
Cc: IETF Discussion List <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <793241C9-C75C-407D-AD98-06E13C789154@ietf.org>
References: <159651200228.24262.1827308624474280314@ietfa.amsl.com> <m2k0yeca1a.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/vugadw-ivDSnjv5oZ8bnPI1fjuY>
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: Tue, 04 Aug 2020 23:16:28 -0000

Thanks for the feedback.

First, just to note that as feedback comes in, a new branch is being updated to address that feedback:

	https://github.com/ietf-llc/infrastructure-and-services-vulnerability-disclosure-statement/blob/latest-updates-from-consultation/DRAFT%20Infrastructure%20and%20Services%20Vulnerability.md

at the time of writing this new branch has updates for the following

- adding more specific timings
- clearer commitment to public disclosure
- clearer scope of covered infrastructure and services

> On 5/08/2020, at 10:37 AM, Randy Bush <randy@psg.com> wrote:
> 
> [ relaying for a friend ]

If your friend doesn’t like email then they can always add a github issue directly.  

> 
>    It's missing a commitment to remedy problems promptly.
>    I don't regard "We aim to address all validated vulnerabilities
>    that are brought to our attention as quickly as possible" as
>    sufficient.

I agree that it would be useful to include a time commitment but we are in an unusual position as a semi-professional/semi-volunteer organisation and it is therefore difficult for us to make commitments about what volunteers can do.  However, combining this with your last point, it’s not unreasonable for us to commit to 90 days so I’ve added an issue to capture that

https://github.com/ietf-llc/infrastructure-and-services-vulnerability-disclosure-statement/issues/5  "Resolutions and disclosure should be no more than 90 days from report".

> 
>    And the "Limitations" section needs work—you often don't
>    know there's a problem without a slight violation of those
>    terms.

It would be useful if your friend could provide details of where these don’t work in practice and suggested fixes.  It would be worth noting though that:

- People often discover problems accidentally, in which case the limitation section does not apply as it is clearly limited to "security research", which by definition is not accidental.

- For security research, these are common limitations and security researchers have well known mechanisms for ensuring they do not stop their work.  For example, one limitation is "Accessing, or attempting to access, data or information that you are not authorised to access." and security researchers will therefore create two accounts or will make arrangements with others to try and access their account and so follow the policy.

- the main reason for including a limitations section is that it enables us to make the commitment "We will not initiate legal action against security researchers attempting to find vulnerabilities within our systems who adhere to this policy." which is considered important by security researchers.

> 
> [ i add ]
> 
> as it differs significantly from the policies of many others, i suspect
> it was overly invented as opposed to borrowed.  this is not fashion in
> security.

I have to challenge that - this is very close to multiple third-party examples and has been almost entirely "borrowed".  

> 
> the current fashion in disclosure window length is 90 days.  no, i do
> not know why if is not three months; but i am sure this list could
> discuss that difference for 90 days.

In response to an earlier reported issue I’ve added a new section specifically on public disclosure (in the branch) and as noted above, I’ll add a 90 day limit to that.

thanks again
Jay

> 
> the llc's proposal should be an internet-draft, please.
> 
> randy
> 

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