Subject: Re: Method of Contact - Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement

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

I would love to see comment on these 2 key questions:

(1) >   * The proposed mechanism for reporting a vulnerability.

When I originally thought about this I was concerned at the default to use email, acknowledging that this is something with which most IETF participants are quite comfortable. I wondered if it might be better to specify that a web interface was the reporting method, which would automatically generate a report ID number on submission that a bug reporter could use for their reference later on. In contrast, an email may not arrive or may be delayed and automatically generating an acknowledgement response with a ticket/tracking number would rely on an additional system that may have communications issues with the email system.

It seems like a web-based reporting system may also provide a better level of security protection by encrypting the channel & contents of the communication vs. less secure email.

(2) >  * What the email address should be for reports to be sent to.

@Jay - Can you list the options being considered here to help aid the discussion?

Thanks
Jason

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Aug 2020 15:22:21 +0000

Be as accepting as possible.  Standard email and a web form could both feed into an autoresponder/ticket system.

>    It seems like a web-based reporting system may also provide a better level of security protection by encrypting the channel & contents of the communication vs. less secure email.

Yeah, TLS is good.

No opinion.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Aug 2020 09:04:52 -0700

> (1) >   * The proposed mechanism for reporting a vulnerability.

the internet operational community focuses on what reporting facility a
*provider* MUST provide, as opposed to restricting what means a reporter
must use.  Cf "abuse-c:" in ripe.

in general, it is operationally strange that your draft seems so focused
on obligations of the researcher as opposed to on the infrastructure
provider.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Aug 2020 15:13:05 -0400

i hate to be late to the party, but..

Is the overall effort here really just framing what the security.txt
for all IETF-LLC properties/things should be?
(also I had thought jim duncan's security.txt thing was long-since a
defacto standard... but: draft-foudil-securitytxt-09 says otherwise,
oops)

> It seems like a web-based reporting system may also provide a better level of security protection by encrypting the channel & contents of the communication vs. less secure email.

I think the easiest thing to use is email, forcing a web interface is
rough on some folks :(
an email to a ticket system with auto-responder (and ideally both gpg
verification inbound and signing outbound) would be nice.
that could be published on the eventual security.txt even :)
  "send gpg signed mail, if you can gpg sign, expect a gpg signed mail
from our ticket system with incident-id"

> @Jay - Can you list the options being considered here to help aid the discussion?

security@ ? :)

---

From: Jay Daley <[email-masked]>
Date: Fri, 7 Aug 2020 07:19:49 +1200

> On 7/08/2020, at 2:59 AM, Livingood, Jason <[email-masked]> wrote:
> 

Just a reminder that a PGP key will be published as part of this policy and referenced in the policy as the means for securing email.  This is again in line with common practice.

> @Jay - Can you list the options being considered here to help aid the discussion?

The well known address is security@ but in the IETF context there are concerns about using [email-masked] as that might be misinterpreted as referring to the SEC area or the general subject of security in the IETF and so the alternative of [email-masked] has been suggested.

Jay

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

---

From: Jay Daley <[email-masked]>
Date: Fri, 7 Aug 2020 07:32:24 +1200

> On 7/08/2020, at 7:13 AM, Christopher Morrow <[email-masked]> wrote:
> 

Is it your recommendation that we publish a security.txt?  If we were to then I would imagine it would do no more than point to this policy.

…

> from our ticket system with incident-id"

Captured the basic part of this as "Automated response should be PGP signed" in https://github.com/ietf-llc/infrastructure-and-services-vulnerability-disclosure-statement/issues/7

>> @Jay - Can you list the options being considered here to help aid the discussion?

See my crossing response about the problem with this - if you have any feedback on that it would be most welcome.

Jay

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 6 Aug 2020 19:35:53 +0000

> Just a reminder that a PGP key will be published as part of this policy and referenced in the policy as the means for securing email.  This is again in line with common practice.

Of course. I'm not sure how universal or easy-to-use PGP email is as compared to just hitting a web page with TLS though...

> The well known address is security@ but in the IETF context there are concerns about using mailto:[email-masked] as that might be misinterpreted as referring to the SEC area or the general subject of security in the IETF and so the alternative of mailto:[email-masked] has been suggested.

In my personal view (*no LLC hat*) it seems odd that this would mean the creation of a new email sub-domain, which seems unnecessarily complicated & unique (having had to deal with mail at a sub-domain for many years at work until we simplified things). So I suppose [email-masked] rather than [email-masked] if my personal preference. As to what the address is, security@, bugreports@ or vulnerabiltyreports@ all seem worth considering.

Jason (sharing personal views)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Aug 2020 16:19:07 +0000

>    It seems like a web-based reporting system may also provide a better level of security protection by encrypting the channel & contents of the communication vs. less secure email.

Separate thread.

You *might* want to accept PGP.  Or put a notice (in the policy, on the website) that since this is handled by a team, rather than have a shared PGP key, use the webform since the PGP will be decrypted once it enters "processing." :)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2020 20:11:19 -0400

Livingood, Jason <[email-masked]> wrote:
    >> Just a reminder that a PGP key will be published as part of this
    >> policy and referenced in the policy as the means for securing email.
    >> This is again in line with common practice.

    > Of course. I'm not sure how universal or easy-to-use PGP email is as
    > compared to just hitting a web page with TLS though...

None of the fuzzing bounty hunters^W^W^Wsecurity researchers who email
tcpdump.org have a problem with email, or PGP email.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2020 18:58:56 -0400 (EDT)

> Is it your recommendation that we publish a security.txt?  If we were to then I would imagine it would do no more than point to this policy.

Please don't publish a security.txt file. See the previous discussions
on SAAG why security.txt is not useful, and actually harmful.

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 8 Aug 2020 23:15:25 -0700

Hi Paul,

> on SAAG why security.txt is not useful, and actually harmful.

I'm not sure that's an accurate characterization of the previous
discussions.  My notes from the IETF LC indicate that it is perceived to be
harmful when used to attempt to report cases of active compromise, but that
there is an important distinction between a state of active compromise and
a state of vulnerability.  I'm happy to have additional discussion on that
matter, but it's probably most appropriate to have it as a continuation of
https://mailarchive.ietf.org/arch/msg/saag/bmsyx9JKnuugpHvajw9svD0B0ks/ .

Thanks,

Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 9 Aug 2020 15:31:23 +0000

>I'm not sure that's an accurate characterization of the previous
    discussions.

I agree that Paul's summary is not correct.