Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

From: Roman Danyliw <[email-masked]>
Date: Wed, 4 Nov 2020 17:31:27 +0000

Hi Dan!

> -----Original Message-----
> From: Roman Danyliw
> Sent: Monday, October 26, 2020 7:51 PM
> To: 'Dan Harkins' <[email-masked]>; [email-masked]
> Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol
> Vulnerabilities
> 
> Hi Dan!
> 
> Thank you for the feedback!
> 
> > -----Original Message-----
> > From: ietf <[email-masked]> On Behalf Of Dan Harkins
> > Sent: Monday, October 26, 2020 12:52 AM
> > To: [email-masked]
> > Subject: Re: Call for Community Feedback: Guidance on Reporting
> > Protocol Vulnerabilities
> >
> >
> >    Howdy,
> >
> >    Not all RFCs are the product of a working group so I think the
> > section dealing with "Expectations from the IETF" should address what
> > the IETF feels it should do wrt to RFCs published by the IETF that
> > were not products of a working group. The existing text seems to only
> > address issues with RFCs that were the produce of a (possibly closed)
> > working group. This probably has an influence on Figure 1 too-- to be
> > specific, before the decision of "4" there should be a decision on the
> > question of whether this is about an RFC that the IETF feels it needs to
> address.
> 
> Good point.  Let me figure out how to best finesse the existence of AD
> sponsored documents, without adding too much (more) complexity.
> 
> Regardless of the editorial approach, let me know if the possible end states
> aren't "errata" (8) or "using the general alias" (10), perhaps with a trip through
> "is there an active working group on the topic" (3).

Please see the revised text to address a workflow for individual submission:

https://github.com/ietf/vul-reporting-guidance/commit/9698c728b900307f74a2649720755b35c6b0523b

Let me know if this doesn't address your feedback.

Thanks,
Roman

> Regards,
> Roman
> 
> >    regards,
> >
> >    Dan.
> >
> > On 10/23/20 11:46 AM, Roman Danyliw wrote:
> > > Hi!
> > >
> > > The Internet Engineering Steering Group (IESG) is seeking community
> > > input on
> > reporting protocol vulnerabilities to the IETF.  Specifically, the
> > IESG is proposing guidance to be added to the website at [1] to raise
> > awareness on how the IETF handles this information in the standards
> > process.  The full text (which would be converted to a web page) is at:
> > >
> > > https://www.ietf.org/media/documents/Guidance_on_Reporting_Vulnerabi
> > > li
> > > ties_to_the_IETF_sqEX1Ly.pdf
> > >
> > > This text is intended to be written in an accessible style to help
> > > vulnerability
> > researchers, who may not be familiar with the IETF, navigate existing
> > processes to disclose and remediate these vulnerabilities.  With the
> > exception of creating a last resort reporting email alias
> > ([email-masked]), this text is describing current
> > practices in the IETF, albeit ones that may not be consistently applied.
> > >
> > > This guidance will serve as a complement to the recently written
> > > IETF LLC
> > infrastructure and protocol vulnerability disclosure statement [2].
> > >
> > > The IESG appreciates any input from the community on the proposed
> > > text and
> > will consider all input received by November 7, 2020.
> > >
> > > Regards,
> > > Roman
> > > (for the IESG)
> > >
> > > [1] This guidance text would be added to a new URL at
> > > https://www.ietf.org/standards/rfcs/vulnerabilities, and then
> > > referenced from www.ietf.org/contact,
> > > https://www.ietf.org/standards/process/,
> > > https://www.ietf.org/standards/rfcs/, and
> > > https://www.ietf.org/topics/security/
> > >
> > > [2]
> > > https://www.ietf.org/about/administration/policies-procedures/vulner
> > > ab
> > > ility-disclosure
> > >
> > >
> >
> > --
> > "The object of life is not to be on the side of the majority, but to
> > escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 6 Nov 2020 02:42:15 +0000

Hi Rich!

> Sent: Monday, October 26, 2020 7:09 PM
> To: 'Salz, Rich' <[email-masked]>; [email-masked]
> Hi Rich!
> Thanks for the review.
> > From: Salz, Rich <[email-masked]>
> > Sent: Friday, October 23, 2020 3:58 PM
> > To: Roman Danyliw <[email-masked]>; [email-masked]
> > I would put the "WE don't pay" sentence at the top, right after the
> > intro paragraph.

The introductory section now closes with this "we don't pay" caution:

https://github.com/ietf/vul-reporting-guidance/commit/edd6ac432d106482a09199bfb9a139c934249577

Regards,
Roman

> Yes, that can added more prominently in the initial introductory text.
> 
> Regards,
> Roman
> 
> > On 10/23/20, 2:46 PM, "Roman Danyliw" <[email-masked]> wrote:
> >
> >     Hi!
> >
> >     The Internet Engineering Steering Group (IESG) is seeking
> > community input on reporting protocol vulnerabilities to the IETF.
> > Specifically, the IESG is proposing guidance to be added to the
> > website at [1] to raise awareness on how the IETF handles this
> > information in the standards process.  The full text (which would be
> converted to a web page) is at:
> >
> >     https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_media_documents_Guidance-5Fon-5FReporting-
> > 5FVulnerabilities-5Fto-5Fthe-5FIETF-
> >
> 5FsqEX1Ly.pdf&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx8
> > 6FtsKI-
> > w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=WZ8lhkI2-
> > LqfcEW09br2ItDhqh8U456y_8xZlTzatI0&e=
> >
> > vulnerability researchers, who may not be familiar with the IETF,
> > navigate existing processes to disclose and remediate these
> > vulnerabilities.  With the exception of creating a last resort
> > reporting email alias ([email-masked]), this text is
> > describing current practices in the IETF, albeit ones that may not be
> consistently applied.
> >
> > IETF LLC infrastructure and protocol vulnerability disclosure statement [2].
> >
> > text and will consider all input received by November 7, 2020.
> >
> >     Regards,
> >     Roman
> >     (for the IESG)
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_standards_rfcs_vulnerabilities&d=DwIFAg&c=96ZbZZcaMF4
> > w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
> >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=lWrYlX1pV0
> > mIGIcyUbXXN4Bl4YdeeGExr508slPDgW8&e= , and then referenced from
> > https://urldefense.proofpoint.com/v2/url?u=http-
> >
> 3A__www.ietf.org_contact&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0
> > GbR0h9Fvx86FtsKI-
> >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=dVVEqnGAgx
> > YTWKmevWh2AwAdymUCMQGs85MMBB2FYPs&e= ,
> > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_standards_process_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6
> > LZg&r=4LM0GbR0h9Fvx86FtsKI-
> > w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=A2QnAr-
> > kezfIPFF3J92rsAfyrfHzpdFR2gquELSO_5w&e= ,
> > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_standards_rfcs_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg
> > &r=4LM0GbR0h9Fvx86FtsKI-
> >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=KtvC1SVlfZT
> > cFhsHQ9RvF_nm856pcSrouxEKNahI5UQ&e= , and
> > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_topics_security_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg
> > &r=4LM0GbR0h9Fvx86FtsKI-
> >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=EN9keXxRYE
> > MvBt-h9ugFVkY3-MUUAv-X9mP7OpOa_po&e=
> >
> >     [2] https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_about_administration_policies-2Dprocedures_vulnerabil
> > ity-
> >
> 2Ddisclosure&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86
> > FtsKI-
> >
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcE
> > omZCLvqzNjCqSADPvsRZPugO5CUryXDI&e=
> >
> >

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 6 Nov 2020 02:45:18 +0000

Hi Eliot!

Merging additional feedback on the executive summary and going for even more simplicity on the process so that the catch-all alias can be mentioned quickly, see the following:

Roman

From: Roman Danyliw
Sent: Wednesday, October 28, 2020 10:53 AM
To: 'Eliot Lear' <[email-masked]>
Cc: The IETF List <[email-masked]>
Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Eliot!

From: Eliot Lear <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 28, 2020 6:34 AM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: The IETF List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Roman,

On 27 Oct 2020, at 20:06, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eliot!

[Roman] In my view, the proposed text effectively says “this is the IETF process and as a last resort, please use the catch all alias”.  My read of your tighter text is the opposite, “here is a new reporting  alias, consider also getting involved in the IETF processes”.  Put in another way, we are actively steering away from established processes (e.g., using the mailing lists) and preferring the triage alias as the first step.  With the reduced text, we are not longer explaining “all the usual processes”.

Ok, Here’s a slightly tweaked version of that text to address how you read the doc:

If you believe you’ve discovered a protocol vulnerability, we very much welcome your contribution.
You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate, in order to discuss protocol improvements to address any vulnerabilities.  If you do not know which IETF working group or mailing list to use or otherwise need help with our processes, we invite you to email “[email-masked]<mailto:[email-masked]>” as well as the document authors, and we will assist you.  All of our work is public, and therefore, disclosing to a working group or mailing list is public.  In some cases, we may ask you to file an erratum, and we will be happy to guide you through that process.

Again, fewer words are better.  And again, adding a few sentences about expectations is just fine.  This should make clear that the mailing list is intended to provide assistance, not triage, and it is entirely optional.

Does that make it clearer that we’re not gate keeping?

[Roman] Indeed it does.  I’d recommend a bit more wordsmithing based on the other feedback provided on payment and inclusion, but the substance is there for me.  Let me get the text into github so edits are easier to manage.

[Roman] To check that we’re on the same page, I see a future version of text like this as the up-front summary.  I believe we still need the existing detailed text to describe the detail process by which to engage the IETF (alluded to in this style of summary).  Agreed?

Regards,
Roman

Eliot

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 6 Nov 2020 11:51:32 +0100

Thanks, Roman.  I appreciate the work.  Please take all of these as suggestions for your consideration, and nothing more (e.g., I’m not pounding my shoe on the table).

My thinking is this:

> Detailed guidance to navigate the disclosure of and remediate of vulnerabilities in the IETF is documented below.

… combined with The Fully Monty below might still leave security researchers with the feel that the onus is on them to drive a process that they may see as daunting.  It is only their responsibility if they wish to take it on.  They may find that it’s easier to talk to a C-Net reporter instead, and then have someone else pick up the work and go through our process if they wish, or not.

The solution for this is probably simple enough: a slight tonal change and a click.  That is:

> Click <here> if you would like to see the full explanation of the process for disclosure and remediation of vulnerabilities.

That gives them a choice in terms of how far down the rabbit hole they want to go with us, but makes clear that there is at least a reporting path if they want to start slowly.

A few other comments:

The scope paragraphs are overly complex.  They can be reduced to the following:

> You can use this disclosure policy to report vulnerabilities in our protocols and technical specifications that you find in either RFCs or our working documents, Internet-Drafts (I-Ds).  You should report specific implementation vulnerabilities to their maintainers, and not to us.  If you spot a vulnerability on our web site or tools, click <here> to report it, and it will be reviewed by the appropriate tooling team.

If you feel more comfortable putting this in passive, that’s a stylistic thing.  I’m an informal guy.

The section title, “Expectations from the IETF” doesn’t quite seem right.  “From” doesn’t usually follow “Expectations”, and the writing below doesn’t make a correction obvious.  I won’t claim to be the world’s best grammarian, but perhaps that’s worth a quick review.

Thanks again for getting this done.

Eliot

> On 6 Nov 2020, at 03:45, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Eliot!
>  
> https://github.com/ietf/vul-reporting-guidance/commit/edd6ac432d106482a09199bfb9a139c934249577 <https://github.com/ietf/vul-reporting-guidance/commit/edd6ac432d106482a09199bfb9a139c934249577>
>  
> Roman
>  
> From: Roman Danyliw 
> To: 'Eliot Lear' <[email-masked] <mailto:[email-masked]>>
> Cc: The IETF List <[email-masked] <mailto:[email-masked]>>
> From: Eliot Lear <[email-masked] <mailto:[email-masked]>> 
> To: Roman Danyliw <[email-masked] <mailto:[email-masked]>>
> Cc: The IETF List <[email-masked] <mailto:[email-masked]>>
> On 27 Oct 2020, at 20:06, Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Eliot!
>  
> You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate, in order to discuss protocol improvements to address any vulnerabilities.  If you do not know which IETF working group or mailing list to use or otherwise need help with our processes, we invite you to email “[email-masked] <mailto:[email-masked]>” as well as the document authors, and we will assist you.  All of our work is public, and therefore, disclosing to a working group or mailing list is public.  In some cases, we may ask you to file an erratum, and we will be happy to guide you through that process.
>  
>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 9 Nov 2020 22:51:37 +0000

Hi Eliot!

From: Eliot Lear <[email-masked]>
Sent: Friday, November 6, 2020 5:52 AM
To: Roman Danyliw <[email-masked]>
Cc: The IETF List <[email-masked]>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

My thinking is this:

A few other comments:

[Roman] Makes sense.  I’ll get another editorial pass factoring this in before we go live.

Thanks,
Roman

Eliot

On 6 Nov 2020, at 03:45, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eliot!

Roman

From: Roman Danyliw
Sent: Wednesday, October 28, 2020 10:53 AM
To: 'Eliot Lear' <[email-masked]<mailto:[email-masked]>>
Cc: The IETF List <[email-masked]<mailto:[email-masked]>>
Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Eliot!

Hi Roman,

Hi Eliot!

Regards,
Roman

Eliot

Eliot

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 9 Nov 2020 22:52:44 +0000

Hi!

Thank you for all of the public and private feedback on this proposed text.  As a result, I think we have much better guidance to post.

There are a few outstanding editorial issues to address which will occur prior publishing.

Thanks again!

Regards,
Roman

> Sent: Wednesday, October 28, 2020 5:30 PM
> To: [email-masked]
> To make it easier to provide updates, the originally referenced PDF has been
> converted to markdown and added to github:
> 
> https://github.com/ietf/vul-reporting-guidance
> 
> Feedback on the text submitted to date with replies to this thread is tracked via
> issues here:
> 
> https://github.com/ietf/vul-reporting-guidance/issues
> 
> Regards,
> Roman
> 
> > From: ietf <[email-masked]> On Behalf Of Roman Danyliw
> > Sent: Friday, October 23, 2020 2:46 PM
> > To: [email-masked]
> > Subject: Call for Community Feedback: Guidance on Reporting Protocol
> > Vulnerabilities
> >
> > Hi!
> >
> > input on reporting protocol vulnerabilities to the IETF.
> > https://www.ietf.org/media/documents/Guidance_on_Reporting_Vulnerabili
> > tie
> > This guidance will serve as a complement to the recently written IETF
> > LLC infrastructure and protocol vulnerability disclosure statement [2].
> >
> > The IESG appreciates any input from the community on the proposed text
> > and will consider all input received by November 7, 2020.
> >
> > Regards,
> > Roman
> > (for the IESG)
> >
> > [2] https://www.ietf.org/about/administration/policies-
> > procedures/vulnerability-disclosure
> >

---

From: Dan Harkins <[email-masked]>
Date: Wed, 18 Nov 2020 17:47:33 -0800

Hi Roman,

> Let me know if this doesn't address your feedback.

   Yes, this does address my comment and I would be happy with this. 
That said,
I think it might be possible to slightly improve things if there was the 
possibility
of a WG looking at fixing an RFC that had been an individual draft. I'm 
thinking of
something like an EAP method that an individual submission. If we can't 
find the
author or the author doesn't care it might make sense to ask EMU if this is
something they might want to look at fixing. In figure 1 I'm thinking of 
maybe
a decision box above 7 that could get the flow into 6 and not terminate 
a 7 if
there's a WG willing to deal with the issue.

   But as I said, I'm happy with what you have so if you want to ignore 
my additional
comment I would be fine with that.

   regards,

   Dan.