Subject: Re: Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement

From: Randy Bush <[email-masked]>
Date: Tue, 04 Aug 2020 15:37:37 -0700

[ relaying for a friend ]

    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.

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

[ 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.

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.

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

randy

---

From: Jay Daley <[email-masked]>
Date: Wed, 5 Aug 2020 11:16:24 +1200

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 <[email-masked]> wrote:
> 

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

>    that are brought to our attention as quickly as possible" as

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

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.

> it was overly invented as opposed to borrowed.  this is not fashion in

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

> 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

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Aug 2020 17:32:35 -0700

> updated to address that feedback:

in what way was i not clear about "internet draft?"  i have a nightly
rsunk direceory of all drafts and have no desire for yet more browser
tabs.

> If your friend doesn’t like email then they can always add a github

my friend already gave at the office.  ex ietf sec ad.  has negative
desire to see anything like an ietf mailing list again.

> 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.

you seem able to make excuses quickly. :)

what you do not seem to understand that the 90 day limit is what folk
will give you.  well, the polite ones.  you can like that or not.

> It would be useful if your friend could provide details of where these
> don’t work in practice and suggested fixes.

have the security ADs and operational security folk helped with this?

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Aug 2020 17:45:15 -0700

> you seem able to make excuses quickly. :)

sorry.  i realize i was being obscure

Others have excuses
But I have my reasons why
-- nickel creek

---

From: Jay Daley <[email-masked]>
Date: Wed, 5 Aug 2020 12:45:55 +1200

> On 5/08/2020, at 12:32 PM, Randy Bush <[email-masked]> wrote:
> 

I’m not sure why, but you omitted my next sentence "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".

BTW 120 days is quite common (e.g ZDI) as is 45 days which is used by many CERTs.

> have the security ADs and operational security folk helped with this?

Yes.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Aug 2020 08:47:57 +0200

On Mon, Aug 03, 2020 at 08:33:22PM -0700,
 IETF Executive Director <[email-masked]> wrote 
 a message of 35 lines which said:

> * Raising an issue on this Github repository

Error 500 "Looks like something went wrong! We track these errors
automatically, but if the problem persists feel free to contact us. In
the meantime, try refreshing."

While MicrosoftHub is being repaired, I suggest here that the draft
mentions draft-foudil-securitytxt and promises to add a security.txt
file. Let's use our techniques, after all.

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Aug 2020 13:22:53 -0700

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.

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.

randy

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 5 Aug 2020 16:31:07 -0400

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

You can do all the editing and issue tracking in GitHub.  However, I agree with Randy this should be posted as an Internet-Draft to facilitate archive and discussion.

Russ

---

From: Jay Daley <[email-masked]>
Date: Thu, 6 Aug 2020 08:55:30 +1200

> On 5/08/2020, at 6:47 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

I’ve added that as an issue in GitHub and I’ve asked the IESG for their view.

https://github.com/ietf-llc/infrastructure-and-services-vulnerability-disclosure-statement/issues/6

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Aug 2020 17:48:07 -0400

+1
And noting that using github in the way it is being used for
this document tends to turn an opportunity for community
discussion of issues into a model in which people offer you
(Jay) advice and you resolve those comments, apparently as you
deem appropriate.  Perhaps that is appropriate for LLC actions
but it is not how the IETF, in my experience at least, normally
does business and is very far from the "decisions are made on
mailing lists" model.  

    john

--On Wednesday, August 5, 2020 16:31 -0400 Russ Housley
<[email-masked]> wrote:

> You can do all the editing and issue tracking in GitHub.
> However, I agree with Randy this should be posted as an
> Internet-Draft to facilitate archive and discussion.

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Aug 2020 17:52:56 -0400

--On Thursday, August 6, 2020 08:55 +1200 Jay Daley
<[email-masked]> wrote:

> I've added that as an issue in GitHub and I've asked the
> IESG for their view.
> 

Jay,

This is another aspect of the issue I raised in my previous
note.  Unless I have misunderstood something very fundamental,
the IESG has no special role here.  Certainly you can ask anyone
(inside or outside the community) for their views, including
that particular collection of people.  But I believe that any
comments should go to this list and be public and (Randy's
friend notwithstanding) attributable, not something provided to
you for your interpretation and action.

   john

---

From: Jay Daley <[email-masked]>
Date: Thu, 6 Aug 2020 10:11:08 +1200

> On 6/08/2020, at 8:22 AM, Randy Bush <[email-masked]> wrote:
> 

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.

> 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

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Thu, 6 Aug 2020 12:00:38 +1200

Russ

> On 6/08/2020, at 8:31 AM, Russ Housley <[email-masked]> wrote:
> 
> Jay:
> 

I should explain the reasons why I don’t use an I-D for such things as this consultation.  In explaining this, I want to note that I still have a lot to learn, may make some incorrect assumptions and have yet to hear from more than a few people on this, so this is by no means set in stone.

1.  Historically,  the way that the LLC and the previous IAD have consulted with the community has not been through I-Ds but through documents with freeform structures.  Here are some examples that predate me:

	https://mailarchive.ietf.org/arch/msg/ietf-announce/cveBTcMiYmD-CB-KT5gn32WGzUI/
	https://mailarchive.ietf.org/arch/msg/ietf-announce/ljcCnToLB9xu-gye3JOS5xBGh7A/
	https://mailarchive.ietf.org/arch/msg/ietf-announce/7qk73shbU23nLADV1wsNhLpdLbM/
	https://mailarchive.ietf.org/arch/msg/ietf-announce/gZXiVvwxpB6iqOr0NDzJiw-5e1Q/

As this is the process that I inherited and most processes here are carefully negotiated over many years and strongly protected once agreed, I chose to stick with that.

2.  Conceptually, the LLC consults on the policies/statements that it needs to document and follow in order to implement the consensus instruction/guidance/delegation it receives from the community in the form of RFCs.  The purpose of LLC consultations is for the LLC to receive community input on these proposed policies/statement and the LLC then decides what of that input to incorporate into the published version.  This is quite distinct from community consensus and the "decisions are made on mailing lists" practice that is a fundamental part of that model.  As you’ll see in John’s reply to your message this is already a matter of confusion for some.  I see it as important that we manage that confusion by separating out both the process for determining community consensus from the consultation process used by the LLC, and the form of the documents and outputs of that process.  

We can then be clear that community consensus, which by its very nature instructs/guides/delegates to the LLC, follows the "I-D -> mailing list decisions -> consensus -> RFC" path, whereas LLC decisions on how it will implement that consensus follow the "proposal -> consultation -> LLC decision -> publication" path.

3.  Practically, the output of these consultations is generally some form of policy/statement that is published on the IETF website and so the consultations consist of two "documents", the transient consultation wrapper and the substantive proposed text that moves towards temporary permanence until it is further reviewed and amended.  This is different from the I-D process where either the whole document is transient as it automatically times out, or it proceeds to genuine permanence as an RFC.  Neither of those paths fit with the way the output of an LLC consultation is used.  

If we use an I-D that times out while the substantive text inside it is published then that could be misleading to those picking up on the process later.  The alternative of the I-D progressing to an RFC is equally problematic as the sorts of policies/statements the LLC consults on will change more regularly than the RFC process is designed for, and more importantly, it is a core part of the LLC construct and my role in particular that the LLC should not have any influence over the standards setting process which becomes messy if the LLC relies on that same process for its own operational policies.

Finally, I would certainly be willing to try and put more structure around our consultations, our policies/statements and even our engagement generally.   Someone not too far from this conversation once suggested that had Internet Operational Notes (RFC4693) worked out and still been in use today then we could square this circle by the LLC drafting and issuing those.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Aug 2020 07:40:19 -0700

> I believe that any comments should go to this list and be public and
> (Randy's friend notwithstanding) attributable

apologies.  my intent was not to hide, but to avoid personalities.  the
comments were by steve bellovin.

randy

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 6 Aug 2020 14:40:46 +0000

As Jay notes, IETF LLC policy consultations to date have occurred primarily in GitHub, with feedback via GH issues & PR, emails, and some webinars. We have gotten a lot of very timely feedback that way and been able to iterate quickly. The consultations have as a result been fast & efficient and have enabled fairly broad engagement/review/comment.

Thanks

Jason

From: ietf <[email-masked]> on behalf of Jay Daley <[email-masked]>
Date: Wednesday, August 5, 2020 at 8:01 PM
To: Russ Housley <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Use of I-Ds by the IETF LLC for consultations (was: Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement)

Russ

On 6/08/2020, at 8:31 AM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Jay:

https://mailarchive.ietf.org/arch/msg/ietf-announce/cveBTcMiYmD-CB-KT5gn32WGzUI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ietf-announce/cveBTcMiYmD-CB-KT5gn32WGzUI/__;!!CQl3mcHX2A!UtK6wD82SdV7r1-nS59r5Pj_O0691NJ8WbyvuMtgOnrL-Ex4TbRM_SnqWRWmvgfuH9tKug$>
https://mailarchive.ietf.org/arch/msg/ietf-announce/ljcCnToLB9xu-gye3JOS5xBGh7A/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ietf-announce/ljcCnToLB9xu-gye3JOS5xBGh7A/__;!!CQl3mcHX2A!UtK6wD82SdV7r1-nS59r5Pj_O0691NJ8WbyvuMtgOnrL-Ex4TbRM_SnqWRWmvgdqdwzCBA$>
https://mailarchive.ietf.org/arch/msg/ietf-announce/7qk73shbU23nLADV1wsNhLpdLbM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ietf-announce/7qk73shbU23nLADV1wsNhLpdLbM/__;!!CQl3mcHX2A!UtK6wD82SdV7r1-nS59r5Pj_O0691NJ8WbyvuMtgOnrL-Ex4TbRM_SnqWRWmvgeoyST9VQ$>
https://mailarchive.ietf.org/arch/msg/ietf-announce/gZXiVvwxpB6iqOr0NDzJiw-5e1Q/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ietf-announce/gZXiVvwxpB6iqOr0NDzJiw-5e1Q/__;!!CQl3mcHX2A!UtK6wD82SdV7r1-nS59r5Pj_O0691NJ8WbyvuMtgOnrL-Ex4TbRM_SnqWRWmvgeNh437iA$>

Jay

--
Jay Daley
IETF Executive Director
[email-masked]<mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Thu, 6 Aug 2020 10:47:31 -0400

Jay:

There are as many examples where I-Ds were used.  Many of those I-Ds were to nail down requirements for tools.  The TLP, which is not an LLC document, did not use an I-D, but in hindsight it would have been better if we had done so.  The TLP is now cited in every RFC.

Russ

> On Aug 5, 2020, at 8:00 PM, Jay Daley <[email-masked]> wrote:
> 
> Russ
> 
>> On 6/08/2020, at 8:31 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Jay:
>> 
> 	https://mailarchive.ietf.org/arch/msg/ietf-announce/cveBTcMiYmD-CB-KT5gn32WGzUI/ <https://mailarchive.ietf.org/arch/msg/ietf-announce/cveBTcMiYmD-CB-KT5gn32WGzUI/>
> 	https://mailarchive.ietf.org/arch/msg/ietf-announce/ljcCnToLB9xu-gye3JOS5xBGh7A/ <https://mailarchive.ietf.org/arch/msg/ietf-announce/ljcCnToLB9xu-gye3JOS5xBGh7A/>
> 	https://mailarchive.ietf.org/arch/msg/ietf-announce/7qk73shbU23nLADV1wsNhLpdLbM/ <https://mailarchive.ietf.org/arch/msg/ietf-announce/7qk73shbU23nLADV1wsNhLpdLbM/>
> 	https://mailarchive.ietf.org/arch/msg/ietf-announce/gZXiVvwxpB6iqOr0NDzJiw-5e1Q/ <https://mailarchive.ietf.org/arch/msg/ietf-announce/gZXiVvwxpB6iqOr0NDzJiw-5e1Q/>
> 
> [email-masked] <mailto:[email-masked]>
>