Thanks, Roman
Great job on describing the "process". Unfortunately, i think our process sucks,
e.g. errata will only be applicable in a small subset of cases.
In general, it will not be possible to find community consensus to resolve
vulnerabilities, and even if there is consensus, doing document updates takes
even longer. Especially because in most cases you want to see good evidence
that the attack vector is likely to be used
(just had a discussion today on dnsop, where the first reaction to a
protocol implementation hardening suggestion i wanted to make in a draft
was rejected with "we have not seen this attack vector being a problem so far").
So, maybe we can while we have time step back a bit and think about what
we could do to incrementally improve our processes:
I would suggest creating two mailing lists:
vulnerability-discuss@xxxxxxxx or vulnerability-dispatch@xxxxxxxx
vulnerability-report@xxxxxxxx
I think we don't need "protocol" in the names, because there are also
vulnerabilities to operational practices from OPS. Or probably
vulnerabilities in data models (hmm... are there ? -).
The first list of course should serve as an easy entry point for anyone
worried about a particular vulnerability or the process and wants to get
answers. And hopefully it can be dispatched to the right WG or more
specific mailing list. And then of course discuss about the process
because with something as new to the IETF as this we probably want to
experiment with the process.
The second list of course is what you called protocol-vulnerability@xxxxxxxx
Ultimately, i think we will have the classical issue that more process on
this front would likely benefit from some intermediate output format
between draft/RFC and errata, i think Warren once called this
"living documents". And i think we should just experiment with that
starting with Wiki or the like.
Cheers
Toerless
On Fri, Oct 23, 2020 at 07:58:29PM +0000, Salz, Rich wrote:
> I would put the "WE don't pay" sentence at the top, right after the intro paragraph.
>
> ???On 10/23/20, 2:46 PM, "Roman Danyliw" <rdd@xxxxxxxx> 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=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=WZ8lhkI2-LqfcEW09br2ItDhqh8U456y_8xZlTzatI0&e=
>
> 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 (protocol-vulnerability@xxxxxxxx), 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_rfcs_vulnerabilities&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=lWrYlX1pV0mIGIcyUbXXN4Bl4YdeeGExr508slPDgW8&e= , and then referenced from https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_contact&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=dVVEqnGAgxYTWKmevWh2AwAdymUCMQGs85MMBB2FYPs&e= , https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_process_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&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=KtvC1SVlfZTcFhsHQ9RvF_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=EN9keXxRYEMvBt-h9ugFVkY3-MUUAv-X9mP7OpOa_po&e=
>
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_administration_policies-2Dprocedures_vulnerability-2Ddisclosure&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcEomZCLvqzNjCqSADPvsRZPugO5CUryXDI&e=
>
>
