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@xxxxxxx> 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@xxxxxxxx
