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

From: Roman Danyliw <[email-masked]>
Date: Fri, 23 Oct 2020 18:46:10 +0000

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_Vulnerabilities_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/vulnerability-disclosure

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Oct 2020 19:58:29 +0000

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

    Hi!

    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= 

    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=

---

From: Dan Harkins <[email-masked]>
Date: Sun, 25 Oct 2020 21:51:45 -0700

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.

   regards,

   Dan.

-- 
"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: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 10:31:46 +0100

Hi Roman,

Thank you for writing this down.  It’s a great initiative.  I would suggest some revision to accomplish two key points in support of the goal encouraging researchers to report problems to us:

Simplify the flow
Make clear their work is appreciated

Starting with the latter, the following statement in the document should be close to the first words read:

“The IETF values your critical analysis of its work.”

That sets the tone for the rest of the document.  You might modify it to capture Rich’s point, “While we are unable to pay bug bounties, The IETF values your critical analysis of its work.”

To make it clear who “your’’ is, you might want to simply state at the beginning of the document, “Dear security researchers”.  That way you can entirely nuke out scope, which most people will just find to be officiousness getting in the way of what they’re really trying to learn, which is how to disclose to the IETF.

Second, it helps to simplify by having a routing function.  Researchers and most others don't want to play Inside Baseball with us.  Since you are already advertising “[email-masked] <mailto:[email-masked]>” why not just let that be the lead point of contact, and say something like this:

If you believe you’ve discovered a protocol vulnerability, we would appreciate it if you were to email “[email-masked] <mailto:[email-masked]>” as well as the document authors.  You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate.  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 errata, and we will guide you through that process.

The idea here is that fewer words are better, and less process put in front of people that will cause them a bad taste is better.  I’m not suggesting those be the only words - talking about how to disclose privately is worth while (IMHO); also setting expectations is important.  Old cruft or non-IETF docs may never get fixed, and even newer stuff might take quite a while.  And encouraging participation in the fix is of course appreciated.  New stuff in drafts might be fixed very quickly!  But I don’t see that it is necessary or helpful to go into too much detail about the structure of our work.  The KISS principle applies.  Thus the diagram should be unnecessary.  If a diagram is necessary, it means KISS has been violated.

Finally, while we might not give bug bounties, we could at least toss these people a tee shirt or a mug, or if nothing else, honorable mention at meetings or in proceedings.  Again, it reinforces that we think their contributions are important.

Best regards,

Eliot

> On 23 Oct 2020, at 20:46, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 26 Oct 2020 12:57:53 +0300

Peace,

> I would put the "WE don't pay" sentence at the top, right after the intro

Vendors might have their own bug bounties for the protocols they
implement.  Nonprofit organizations might have bounties for protocol
security research, to ensure safer Internet in general.  Looking for those
should be suggested then.  "We don't pay" is a powerful message which, when
it comes down to a typical Initech, generally implies "we don't care".

A list of sponsoring and shepherding organizations offering bounties for
vulnerabilities found in the WG documents might be published for each of
the WGs (just a suggestion).  One might argue then that processing
potential vulnerabilities through the IETF process might be easier together
with points of contact in those vendors who were responsible for document
development and implementation, as opposed to doing it with the
vulnerability researchers directly.  For those researchers, IETF processes
might seem, well, unusual.

--
Töma

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2020 07:27:48 -0400

Eliot, those are some awesome edits.

Eliot Lear <lear=[email-masked]> wrote:
    > Second, it helps to simplify by having a routing function.  Researchers
    > and most others don't want to play Inside Baseball with us.  Since you
    > are already advertising “[email-masked]
    > <mailto:[email-masked]>” why not just let that be the
    > lead point of contact, and say something like this:

What is going to behind this address?
It says a non-public archive.

So it needs to be something people can send to without subscription.
It needs to go into a ticket system that can acknowledge the submission. (RT,
whatever).   We'll probably have to have someone delete the spam.
It might be worth having a return reachability check on the email to help
reduce the spam load.

It would be nice if it could show up in author's DT account to respond, on
record.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 20:37:07 +0100

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:

  [email-masked] or [email-masked]
  [email-masked]

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

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:
> ???On 10/23/20, 2:46 PM, "Roman Danyliw" <[email-masked]> wrote:
> 
>     Hi!
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 26 Oct 2020 23:58:33 +0400

> 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 vuln…

I've spoken to a few security researchers and asked why they aren't
willing to talk to the IETF. From their reply, it seems that they see
the IETF as being "complicated". I welcome the document as it's a step
forward in the right direction.

 There have been cases where security researchers feel that the
organizations are taking too long and then they decide to publish full
details including Proof of Concept. I think that the document should
encourage researchers to wait before releasing full PoC until the
proper errata has been published.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 21:09:53 +0100

> proper errata has been published.

How do you even qualify vulnerabilities as something other than
 "text we could have added to the security considerations section, but
nobody thought the attack vector would be expoited" ?

Other question:

How do you decide between protocol and implemntation ? E.g.: the distinction
between IKEv2/ESP allows me to implement better defense against DoS with
advanced endpoint hardware. TLS does not have this. So ... implementation or
protocol issue ?

Toerless

-- 
---
[email-masked]

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 26 Oct 2020 23:41:12 +0000

Hi Rich!

Thanks for the review.

> -----Original Message-----
> From: Salz, Rich <[email-masked]>
> Sent: Friday, October 23, 2020 3:58 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol
> Vulnerabilities
> 

Yes, that can added more prominently in the initial introductory text.

Regards,
Roman

>     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=
> 
>     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://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_vulnerability-
> 2Ddisclosure&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86
> FtsKI-
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcE
> omZCLvqzNjCqSADPvsRZPugO5CUryXDI&e=
> 
>

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 27 Oct 2020 11:56:35 +0000

Hi Dan!

Thank you for the feedback!

> From: ietf <[email-masked]> On Behalf Of Dan Harkins
> Sent: Monday, October 26, 2020 12:52 AM
> To: [email-masked]
>    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).

Regards,
Roman

> > 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:
> >
> > 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)
> >
> > 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/vulnerab
> > 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: Tue, 27 Oct 2020 11:56:36 +0000

Hi Eliot!

Thanks for the review.  Inline …

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

Hi Roman,

  *   Simplify the flow
  *   Make clear their work is appreciated

[Roman]  Point taken.  The opening can be even stronger about encouraging input.

Second, it helps to simplify by having a routing function.  Researchers and most others don't want to play Inside Baseball with us.  Since you are already advertising “[email-masked]<mailto:[email-masked]>” why not just let that be the lead point of contact, and say something like this:

If you believe you’ve discovered a protocol vulnerability, we would appreciate it if you were to email “[email-masked]<mailto:[email-masked]>” as well as the document authors.  You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate.  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 errata, and we will guide you through that process.

[Roman] I like you words.  They are more consistent with common industry practice that attempts to simplifying the onus of the reporting process and an understood workflow around it.  The new LLC vulnerability disclosure policy (https://www.ietf.org/about/administration/policies-procedures/vulnerability-disclosure) takes this same approach.

[Roman] The text proposed for the vulnerability reporting web page is longer (and more complex and certainly not KISS), but significantly less ambitious than yours in scope.  It appear that your concise text would redefine the IETF culture and process about handling a certain class of information.  That’s a big step that would require a comprehensive discussion and deliberate consensus process around it.  What’s being proposed instead is an initial outreach step with a “Tao of the IETF”-style prose which explains the as-is process to an IETF newcomer on reporting vulnerability information – almost no new process/culture invented (there will be a new email alias which will act as a final catch all).

[Roman] Completely agree.  These are nice gestures that should be considered.  Additionally, I’ve seen partnerships between the IETF and professional societies to create venues to showcase cutting edge security analysis on IETF work but also be peer-reviewed to contribute to a publication record.  That said, the proposal is web-page text to describe how the IETF works, not new process.

Regards,
Roman

Best regards,

Eliot

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

Hi!

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]<mailto:[email-masked]>), this text is describing current practices in the IETF, albeit ones that may not be consistently applied.

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<http://www.ietf.org/contact>, https://www.ietf.org/standards/process/, https://www.ietf.org/standards/rfcs/, and https://www.ietf.org/topics/security/

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 27 Oct 2020 11:56:35 +0000

Hi Toerless!

Thanks for the review.  Inline ...

> From: Toerless Eckert <[email-masked]>
> Sent: Monday, October 26, 2020 3:37 PM
> To: Salz, Rich <rsalz=[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked]
> (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 want to separate the above into discrete problems in the vulnerability coordination process -- there is the reporting (how and to who to convey the information), validation/triage (how to ensure the accuracy of the information) and remediation (what does one do about it).  No question that the processes by which the community finds consensus on the remediation is challenging.  As might be convincing a recipient on the validating of the vulnerability to begin with.  However, neither of these is the scope of the proposal which is intended to be a much less ambitious scope -- how to _report_ the vulnerability to the IETF.

>   [email-masked]

Point taken about the different between issues with operational practices and protocol vulnerabilities.

The thinking behind the last-resort alias name (protocol-vulnerability@ietf) was to provide sufficient distance from future WG names (*-dispatch@ietf), the LLC disclosure alias ([email-masked]), and any sense of it looking like it was triaging implementation issues.

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

As I noted in my response to Eliot, the IETF could definitely go this way and have a centralized reporting, triage and dispatch process.  However, this would require a deliberate, consensus process.  The proposal here is a text for the website to explain what we do now.

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

There is no reason why we couldn't put this text on a wiki, however it might be less impactful there.  The thinking was to make the text prominent on the main website.

Regards,
Roman

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_medi
> > a_documents_Guidance-5Fon-5FReporting-5FVulnerabilities-5Fto-5Fthe-5FI
> > ETF-
> 6F
> > tsKI-
> >     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-
> [email-masked]), this text is describing current practices in the IETF,
> albeit ones that may not be consistently applied.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_stan
> >
> dards_rfcs_vulnerabilities&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0
> GbR
> > 0h9Fvx86FtsKI-
> w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=lWrYlX
> > 1pV0mIGIcyUbXXN4Bl4YdeeGExr508slPDgW8&e= , and then referenced from
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_conta
> > ct&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
> w&m=ZJ9CHN
> >
> axYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=dVVEqnGAgxYTWKmevWh
> 2AwAdymUCMQ
> > Gs85MMBB2FYPs&e= ,
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_stan
> >
> dards_process_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx
> 86FtsK
> > I-w&m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=A2QnAr-
> kezfIPFF3J9
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_stan
> >
> dards_rfcs_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86F
> tsKI-w
> >
> &m=ZJ9CHNaxYta4Rwzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=KtvC1SVlfZTcF
> hsHQ9RvF
> > _nm856pcSrouxEKNahI5UQ&e= , and
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_topi
> >
> cs_security_&d=DwIFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86
> FtsKI-
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_abou
> > t_administration_policies-2Dprocedures_vulnerability-2Ddisclosure&d=Dw
> > IFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
> w&m=ZJ9CHNaxYta4R
> >
> wzv9CsBCZ7S64SWbQDTXAsV8KWP_AU&s=VAKeetf0jcEomZCLvqzNjCqSADPvs
> RZPugO5C
> > UryXDI&e=
> >
> >

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Oct 2020 13:20:18 +0100

Hi Roman and thanks for the feedback.  Just on this point…

> On 27 Oct 2020, at 12:56, Roman Danyliw <[email-masked]> wrote:
> 

I certainly didn’t set out to change culture OR process.  How do you think I’ve done that?  Perhaps it sounded as if the mailing list is intended to gate keep?  Certainly not what I had in mind.  Just to route. All the usual processes would still apply to what happens next, and the routing function should not be lossy.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Oct 2020 14:09:04 +0100

Roman:

What you describe in the text is already suficiently convoluted (yepp, that's
what we are, you can't significanlty simplify it ;-)) that anyone not already
actively engaged in the IETF for longer would certainly be confused enough to
have question about process, how to follow up from reporting, looking for
help and so on. Hence the proposal to not only set up a list like
[email-masked], but also an open discussion mailing lists
[email-masked] so that there is at least an easy, open point to discuss.

Or let me put it differently: I would not like for IETF to pick up on
a process like vulnerability reporting if it ends up being solely behind
closed doors without having a list for the community and those we want to
attact to discuss it. As any non-WG mailing list, discussion doesn't mean
to give any responsibility to produce IETF output to such a list.

Of course your text should go to the web page. I was merely pointing out
that anything beyond the established process we have today might want to
be starting less informal, as i think we wouldn't know by now what an ideal
process would be.

Finally: don't worry about taking the word "vulnerability" away from possible
later WGs. Its always been FCFS on names.

Cheers
    toerless

-- 
---
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Oct 2020 13:59:35 +0000

Having worked on OpenSSL for many years, the absolute worst thing you can do is not respond to reported vulnerabilities.  Even if it’s just an auto-reply that says “thanks we got it.”

I also think it would be worth pointing out more strongly that we are interested in *protocol* errors, not *implementation* errors, and making that distinction clear.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Oct 2020 15:26:12 +0100

On Tue, Oct 27, 2020 at 01:59:35PM +0000, Salz, Rich wrote:
> Having worked on OpenSSL for many years, the absolute worst thing you can do is not respond to reported vulnerabilities.  Even if it???s just an auto-reply that says ???thanks we got it.???
> 

Again, just to re-emphasize my desire that three should be an open discussion list for
vulnerabilities (vulnerability-discuss), because IMHO this is one of the likely repeatedly
 incurring points of contentions as to where to draw the line. Which IMHO needs to be explored.

One initial definition might be "implementation error is one that can be fixed without
changing the protocol spec text" (i guess, i have not seen a better definition).

So lets say i have seen enough cases where routers stopped forwarding any traffic because
they ran out of memory because someone attacked the router creating to much protocol
state. Lets pick your poison, in my case it was easily user generated multicast state,
others may prefer BGP or IGPs.

So... should the protcol spec have a requirement stating that implementations
MUST ensure this can not happen, and - oh, go figure out how to do that, not a
protocol issue ?

In patents, patent protection is only granted when the description is
sufficient to build a working model. So if you want to claim that a protocol
is not at fault for an attack, its description needs to be sufficient to
make it clear how to build a working model protecting against the attack.

If you apply that guideline to IETF protocol specs, you will draw blanks all
over the place. At least in routing.

Cheers
    Toerless

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Oct 2020 14:52:01 +0000

I am not sure what you are trying to say.  That it's hard to determine where the fault is sometimes?  I don't think anyone disagrees with that.

I worry about something like "[email-masked]" becoming swamped with implementation issues, but I would support this if we agreed it was a two-year experiment or something.

Patents (at least in the US) typically have an "escape clause" near the beginning, often written like "As will be readily obvious to one familiar with the field"  So I see the same parallel to standards: avoiding memory exhaustion under load should be readily obvious to one familiar with the field.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 08:17:29 -0700

On 10/27/20 5:20 AM, Eliot Lear wrote:
>> On 27 Oct 2020, at 12:56, Roman Danyliw <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> [Roman] The text proposed for the vulnerability reporting web page is 
>> longer (and more complex and certainly not KISS), but significantly 
>> less ambitious than yours in scope.  It appear that your concise text 
>> would redefine the IETF culture and process about handling a certain 
>> class of information.  That’s a big step that would require a 
>> comprehensive discussion and deliberate consensus process around it. 
>>  What’s being proposed instead is an initial outreach step with a 
>> “Tao of the IETF”-style prose which explains the as-is process to an 
>> IETF newcomer on reporting vulnerability information – almost no new 
>> process/culture invented (there will be a new email alias which will 
>> act as a final catch all).
>
>
> I certainly didn’t set out to change culture OR process.  How do you 
> think I’ve done that?  Perhaps it sounded as if the mailing list is 
> intended to gate keep?  Certainly not what I had in mind.  Just to 
> route. All the usual processes would still apply to what happens next, 
> and the routing function should not be lossy.
>
So coming in here a bit late, but isn't the basic problem is that 
working groups don't want to hear criticism or take it seriously? So if 
you figure out problems with the protocol it's pushing on string at best 
and snarl inducing at worst. It would be great if working groups were 
receptive to issues, but there is every incentive to ignore or ridicule 
problems. And then of course there is the problem that there may not be 
a working group anymore.

Mike, who has experienced this repeatedly

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Oct 2020 12:15:57 -0400

Salz, Rich <rsalz=[email-masked]> wrote:
    >> Having worked on OpenSSL for many years, the absolute worst thing you
    >> can do is not respond to reported vulnerabilities.  Even if it’s just an
    >> auto-reply that says “thanks we got it.”

Agreed.  And this is a place where I think it's worth having a link sent to
them that they can manage their report. (With a JWT bearer token of course)
That way, we can age-out reports for which the link was never followed,
otherwise the spam load is going to kill us.

    > I also think it would be worth pointing out more strongly that we are
    > interested in *protocol* errors, not *implementation* errors, and
    > making that distinction clear.

Given the number of people who can't distinguish openssh from openssl, I am
rather skeptical that we will get far here.   I think that we will need a
button sending implementation/protocol FAQ, and it's probably not
unreasonable that we might need three iterations to get that explanation
right, and perhaps even engage some kind of communications expert to help us
draft it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Oct 2020 12:24:36 -0400

I am not sure that we can define a process. A meta-process is probably
better. Every issue tends to be different. Take the response to the
Kaminsky attack for instance, that wasn't really a protocol error, it was
an implementation issue. But the nexus of developers was here.

What we need is to balance the need to prevent hostile exploits of a
vulnerability and providing a forcing function to get things done.

I am not at all impressed by certain companies who have a policy of
disclosing vulnerabilities in their competitor's products on a fixed
timetable of their choosing. On the other hand, I did tell Netscape about
the issues in their random number generation system 18 months before they
were rediscovered by reverse engineering the code.

A good rule of thumb that I try to follow is to consider how I would
respond (or tell my CEO to respond) if asked to defend my actions in a
Congressional hearing. That was not a purely theoretical possibility in the
1990s.

On Mon, Oct 26, 2020 at 3:37 PM Toerless Eckert <[email-masked]> wrote:

> >     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:
> >
> >
> 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)
> >
> 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=
> >
> >
>
>

---

From: [email-masked]
Date: Tue, 27 Oct 2020 09:48:10 -0700 (PDT)

Michael Thomas <[email-masked]> wrote:

> and snarl inducing at worst.

I've been on both the sending and receiving end of many security concerns, both
here and elsewhere. This includes, but is not limited to, my work as a media
types reviewer for 20+ years, where I've written dozens of responses, including
responses to working groups, pointing out inadequate security considerations.

In all of that, I can count the number of times where my concerns were ignored
or not taken seriously on the fingers of one hand. And while I'm obviously not
the best judge when I'm on the receiving end, I can't think of a time when I've
observed the sort of behavior you describe in a working group.

What does happen sometimes is someone raises what is effectively a nonissue:
It's either already been dealt with, so trivial it's not worth the bits to
describe, out of scope, or simply nonsense. And when they are told as much,
sometimes they get upset.

> It would be great if working groups were

Really? And what happens when the RFC is published without having addressed or
at least acknowledged the concern, and whoever raised it points it out to the
trade press?

This sounds like an incredibly short-sighted, not to mention potentially
reputation-destroying, approach to me.

> Mike, who has experienced this repeatedly

			Ned, who has not.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 10:48:41 -0700

> observed the sort of behavior you describe in a working group.

The most recent was with the STIR wg. I found some problems and brought 
it up on the working group list and was ignored. This was after they had 
issued RFC 8226 so I interpreted it at the time as just not wanting 
revisit anything. I started writing a blog post about the things I 
found, but ended giving up because there were so many things 
wrong/underspecified. I then went through the wg archives and saw that 
Dave Crocker had written a list of about 100 things that were 
wrong/questionable at last call almost all of which were ignored. Worse: 
there wasn't much intersection between our lists. So that reads to me as 
a wg that isn't interested in hearing about problems. The same thing 
happened to me commenting on OAUTH which caused the then editor to go 
ballistic. None of this should be especially surprising: nobody likes 
somebody attacking (literally in the case of security) their baby.

> sometimes they get upset.

In the OAUTH case it was -- and is -- a critical problem in the 
applicability of when you can safely use OAUTH. Browser, groovy. Native 
apps, bad. How many native apps use OAUTH these days? Lots? It got one 
sentence buried in the security considerations for my effort. It 
manifestly didn't change (m)any outcomes.

Mike

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Oct 2020 19:00:26 +0100

I think what you are pointing out is that maybe it would help if these things were properly tracked against anything that would update or obsolete existing work.  We might even be able to automate the response along the lines of:

A working group is currently working on an update.  Please feel free to join in the fun at...
A working group is currently working on a replacement (e.g., obsolete). Please feel free to join in the fun at ...
No current update is in progress.  In addition to filing an erratum, we invite you to provide an update through our errata process, and perhaps through our standards process.  You can contact <insert AD here> for more information.

Or some such.

Eliot

> On 27 Oct 2020, at 18:48, Michael Thomas <[email-masked]> wrote:
> 
> 
> The most recent was with the STIR wg. I found some problems and brought it up on the working group list and was ignored. This was after they had issued RFC 8226 so I interpreted it at the time as just not wanting revisit anything. I started writing a blog post about the things I found, but ended giving up because there were so many things wrong/underspecified. I then went through the wg archives and saw that Dave Crocker had written a list of about 100 things that were wrong/questionable at last call almost all of which were ignored. Worse: there wasn't much intersection between our lists. So that reads to me as a wg that isn't interested in hearing about problems. The same thing happened to me commenting on OAUTH which caused the then editor to go ballistic. None of this should be especially surprising: nobody likes somebody attacking (literally in the case of security) their baby.
> 
>> 
> In the OAUTH case it was -- and is -- a critical problem in the applicability of when you can safely use OAUTH. Browser, groovy. Native apps, bad. How many native apps use OAUTH these days? Lots? It got one sentence buried in the security considerations for my effort. It manifestly didn't change (m)any outcomes.
> 
> Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 11:27:13 -0700

On 10/27/20 11:00 AM, Eliot Lear wrote:
> I think what you are pointing out is that maybe it would help if these 
> things were properly tracked against anything that would update or 
> obsolete existing work.  We might even be able to automate the 
> response along the lines of:
>
>   * A working group is currently working on an update.  Please feel
>     free to join in the fun at...
>   * A working group is currently working on a replacement (e.g.,
>     obsolete). Please feel free to join in the fun at ...
>   * No current update is in progress.  In addition to filing an
>     erratum, we invite you to provide an update through our errata
>     process, and perhaps through our standards process.  You can
>     contact <insert AD here> for more information.
>
>
My impression is that errata has a pretty high barrier to entry if it's 
potentially controversial. There doesn't seem to be any easy mechanism 
to do a one off update that requires wg buy in to get enough eyeballs on 
the problem to make certain that the fix is correct. it's like you need 
something similar to a critical security update to your OS, say, which 
needs to be well vetted by the devs, but doesn't want to wait for the 
next point release.

If errata is that mechanism for something controversial, it's news to 
me. Mostly what i've seen with errata are minor fixes which the wg chair 
and/or authors can sign off easily.

Mike

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 27 Oct 2020 19:06:44 +0000

Hi Eliot!

Sent: Tuesday, October 27, 2020 8:20 AM

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

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

Roman

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 27 Oct 2020 19:48:48 +0000

Hi Toerless!

> Sent: Tuesday, October 27, 2020 9:09 AM
> Cc: Salz, Rich <rsalz=[email-masked]>; [email-masked]
> have question about process, how to follow up from reporting, looking for help
> and so on. Hence the proposal to not only set up a list like vulnerability-
> [email-masked], but also an open discussion mailing lists vulnerability-
> [email-masked] so that there is at least an easy, open point to discuss.
>
> Or let me put it differently: I would not like for IETF to pick up on a process like
> vulnerability reporting if it ends up being solely behind closed doors without
> having a list for the community and those we want to attact to discuss it. As
> any non-WG mailing list, discussion doesn't mean to give any responsibility to
> produce IETF output to such a list.
>
> Of course your text should go to the web page. I was merely pointing out that
> anything beyond the established process we have today might want to be
> starting less informal, as i think we wouldn't know by now what an ideal
> process would be.

Sure.  Irrespective of what we do with the proposed text or future process, we can definitely create non-WG mailing list to discuss vulnerability disclosure processes in the IETF.  

To be clear, this list isn't intended to handle actual vulnerability information, but to discuss the processes by which the IETF might want to handle it, right?

Regards,
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
> > >
> > > 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 want to separate the above into discrete problems in the vulnerability
> coordination process -- there is the reporting (how and to who to convey the
> information), validation/triage (how to ensure the accuracy of the information)
> and remediation (what does one do about it).  No question that the processes
> by which the community finds consensus on the remediation is challenging.  As
> might be convincing a recipient on the validating of the vulnerability to begin
> with.  However, neither of these is the scope of the proposal which is intended
> to be a much less ambitious scope -- how to _report_ the vulnerability to the
> IETF.
> >
> > The thinking behind the last-resort alias name (protocol-vulnerability@ietf)
> was to provide sufficient distance from future WG names (*-dispatch@ietf), the
> LLC disclosure alias ([email-masked]), and any sense of it
> looking like it was triaging implementation issues.
> >
> > > I think we don't need "protocol" in the names, because there are
> > > also vulnerabilities to operational practices from OPS. Or probably
> > > 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.
> > >
> > As I noted in my response to Eliot, the IETF could definitely go this way and
> have a centralized reporting, triage and dispatch process.  However, this would
> require a deliberate, consensus process.  The proposal here is a text for the
> website to explain what we do now.
> >
> > > 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.
> >
> > There is no reason why we couldn't put this text on a wiki, however it might
> be less impactful there.  The thinking was to make the text prominent on the
> main website.
> >
> > Regards,
> > Roman
> >
> >
> > > Cheers
> > >     Toerless
> > >
> > >
> > > > I would put the "WE don't pay" sentence at the top, right after
> > > > the intro
> > > paragraph.
> > > >
> > > 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:
> > > >
> > > >
> > > 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- [email-masked]), this text
> > > is describing current practices in the IETF, albeit ones that may not be
> consistently applied.
> > > >
> > > > I-

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 27 Oct 2020 15:27:54 -0500

On 27 Oct 2020, at 12:48, Michael Thomas wrote:

> The most recent was with the STIR wg. I found some problems and 
> brought it up on the working group list and was ignored. This was 
> after they had issued RFC 8226 so I interpreted it at the time as just 
> not wanting revisit anything. I started writing a blog post about the 
> things I found, but ended giving up because there were so many things 
> wrong/questionable at last call almost all of which were ignored. 
> Worse: there wasn't much intersection between our lists. So that reads 
> to me as a wg that isn't interested in hearing about problems. The 
> same thing happened to me commenting on OAUTH which caused the then 
> editor to go ballistic. None of this should be especially surprising: 
> nobody likes somebody attacking (literally in the case of security) 
> their baby.

So I presume you walked through the conflict resolution and appeals 
process, in the case of STIR starting with the STIR Chair, the ART Area 
Director, and/or the IESG as per RFC 2026 6.5.1, and in the case of 
OAUTH with the OAUTH Chair, the SEC Area Director and/or the IESG?

6.5.1 Working Group Disputes

    An individual (whether a participant in the relevant Working Group 
or
    not) may disagree with a Working Group recommendation based on his 
or
    her belief that either (a) his or her own views have not been
    adequately considered by the Working Group, or (b) the Working Group
    has made an incorrect technical choice which places the quality
    and/or integrity of the Working Group's product(s) in significant
    jeopardy.  The first issue is a difficulty with Working Group
    process;  the latter is an assertion of technical error.  These two
    types of disagreement are quite different, but both are handled by
    the same process of review.

    A person who disagrees with a Working Group recommendation shall
    always first discuss the matter with the Working Group's chair(s),
    who may involve other members of the Working Group (or the Working
    Group as a whole) in the discussion.

    If the disagreement cannot be resolved in this way, any of the
    parties involved may bring it to the attention of the Area
    Director(s) for the area in which the Working Group is chartered.
    The Area Director(s) shall attempt to resolve the dispute.

    If the disagreement cannot be resolved by the Area Director(s) any 
of
    the parties involved may then appeal to the IESG as a whole.  The
    IESG shall then review the situation and attempt to resolve it in a
    manner of its own choosing.

    If the disagreement is not resolved to the satisfaction of the
    parties at the IESG level, any of the parties involved may appeal 
the
    decision to the IAB.  The IAB shall then review the situation and
    attempt to resolve it in a manner of its own choosing.

    The IAB decision is final with respect to the question of whether or
    not the Internet standards procedures have been followed and with
    respect to all questions of technical merit.

Particularly in the case of OAUTH, if a document editor is misbehaving, 
then that needs to be dealt with. All it takes is an email message to 
start.

Unless you actually engaged with the process and actually made 
leadership aware that something was going pear-shaped, I'm not terribly 
sympathetic.

People seem very unwilling to walk through the conflict resolution and 
appeals process, and it's absolutely essential to the good functioning 
of the IETF that people use it from time to time. Again, the start of it 
is simply an email message to the chair saying "My comments are being 
ignored" or "The WG screwed up and made a bad technical choice". If you 
don't like the answers you get, well that's a different thing, but if 
you haven't actually engaged, you have only yourself to blame.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Oct 2020 20:46:25 +0000

> but if 

I am more sympathetic, for a couple of reasons

- The "what to do if treated wrongly" procedures are not well-known.  For example, they aren't in the newcomer's tutorials, nor in any recent reminders that I've seen.

- Particularly for newcomers, being on the wrong side of "jerky" behavior can be off-putting, and definitely lead to just walking away; life's too short.

Not proposing any solutions right now as I don't have any good ideas.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 14:16:48 -0700

On 10/27/20 1:27 PM, Pete Resnick wrote:
>> after they had issued RFC 8226 so I interpreted it at the time as 
>> just not wanting revisit anything. I started writing a blog post 
>> about the things I found, but ended giving up because there were so 
>> many things wrong/underspecified. I then went through the wg archives 
>> and saw that Dave Crocker had written a list of about 100 things that 
>> were wrong/questionable at last call almost all of which were 
>> ignored. Worse: there wasn't much intersection between our lists. So 
>> that reads to me as a wg that isn't interested in hearing about 
>> problems. The same thing happened to me commenting on OAUTH which 
>> caused the then editor to go ballistic. None of this should be 
>> especially surprising: nobody likes somebody attacking (literally in 
>> the case of security) their baby.
>
> process, in the case of STIR starting with the STIR Chair, the ART 
> Area Director, and/or the IESG as per RFC 2026 6.5.1, and in the case 
> of OAUTH with the OAUTH Chair, the SEC Area Director and/or the IESG?

Why on earth would I want to be a drama queen? Especially since I had no 
dog in either fight?

>
> Particularly in the case of OAUTH, if a document editor is 
> misbehaving, then that needs to be dealt with. All it takes is an 
> email message to start.

Barry handled the author fine, iirc. It's just that wg as a whole 
dismissed the problem even though what I predicted is exactly what 
happened. They wrote my concern into the security requirements with like 
a one sentence dismissal and everybody ignored it.

> leadership aware that something was going pear-shaped, I'm not 
> terribly sympathetic.

Isn't this thread about getting outside clue to the attention of the 
working groups more seamlessly? Your quoted process and sympathy is 
exactly the wrong way to foster that.

> of the IETF that people use it from time to time. Again, the start of 
> it is simply an email message to the chair saying "My comments are 
> being ignored" or "The WG screwed up and made a bad technical choice". 
> If you don't like the answers you get, well that's a different thing, 
> but if you haven't actually engaged, you have only yourself to blame.
>
>
In OAUTH's case I did talk to Barry. For STIR after seeing what they did 
to Crocker at last call it was apparent that it would fall on deaf ears 
so why bother? I did bring it up my concern on their mailing list before 
I read the archives, but crickets. The flip side of this that nobody 
wants to be seen as an insane Casandra in case you are actually wrong.

If you want outside clue but the reality is that they treat you as the 
enemy, you're not going to get the desired result. Any fix for this 
needs to account for that.

Mike

---

From: [email-masked]
Date: Tue, 27 Oct 2020 16:29:51 -0700 (PDT)

Michael Thomas <[email-masked]> wrote:

> >> just not wanting revisit anything.

RFC publication removes the work item from the WG's to-do list. Even if it
wanted to the WG cannot change the RFC willy-nilly; the WG would have to be
rechartered in order to do the work. That's intentionally a very substantial
bar to doing that.

> >> I started writing a blog post
> >> many things wrong/underspecified.

The document is 26 pages long. I find it hard to believe it's impossible to
list all the problems you found.

> >> I then went through the wg archives
> >> ignored.

I tracked down what I think is the message you're referring to - which was sent
back back in 2016:

  https://mailarchive.ietf.org/arch/msg/stir/VkB0HMs5JrHRLcOrDmMukdIzD3A/

I'm afaid your claim that the issues raised were all ignored is simply false.
Sean Turner responded point by point to Dave's message here:

  https://mailarchive.ietf.org/arch/msg/stir/g1miP5WFuDolrjjZ8IK-VKxR5SI/

Now, you may not agree with that response. You may think that Dave was correct
in every point and Sean was wrong, and it may be the case that none of the
points were ever addressed to Dave's satisfaction. But this is all beside the
point: There's a big difference between not getting what you want and being
ignored.

I note in passing that there was enough wrong with the document that it went
through another two years of work and another last call. So it's not at all
like it didn't undergo signiicant review and revision after that.

> >> Worse: there wasn't much intersection between our lists. So
> >> problems.

Whereas it reads to me like a WG that didn't agree with the issues raised by
one participant, and that you were late to the party and decided not to avail
yourself of the processes used to report problems with an RFC.

> >> The same thing happened to me commenting on OAUTH which

Your choice of words here speaks volumes... Of course nobody like being
attacked; why on earth would thay? But only a fool rejects valid constructive
criticism, especially when doing so will sifnificantly improve the result.

Now FWIW, I think the right thing to do with attacks - and I've been on the
receiving end of some real doozies - is to ignore the vitriol and look for the
actual critique, assuming there is one. And if it is valid, deal with it
appropriately, even if you don't respond directly.

> Why on earth would I want to be a drama queen? Especially since I had no

So what you're saying is that only drama queens avail themselves of the 
processes put in place to deal with exactly the isues you say you had?
Processes that a lot of people worked very hard to devise and who many, myself
included, take very seriously?

Of course you have a right to believe whatever you want, even if that belief
limits your own options. But doing so is entirely your choice.

				Ned

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 18:14:37 -0700

> rechartered in order to do the work. That's intentionally a very 
This thread is about what happens when people find things that are 
broken in protocols. If you think that ossification is an acceptable 
outcome just say so.
> list all the problems you found.

Look in the email archives. I can't believe that I have to defend Dave 
as well as myself. They treated him like shit.

> point: There's a big difference between not getting what you want and 

This is a strawman. I said that most of Dave's problems were ignored and 
that there was a lot of snarling about it being brought up in last call. 
Peterson in particular impugned Crocker for that, as if last call was a 
bad time for comments.

> like it didn't undergo signiicant review and revision after that.
When I looked at it years later it was like "holy shit, what a mess". 
That was well before I saw Crocker's comments.

I came upon it completely in an orthogonal way thinking it was probably 
DKIM-like trying to understand what they actually did. It took me a very 
long time to understand that it wasn't and was a complete mess. It took 
me months to get answers of what in hell was going on. Have you actually 
looked at it? It's a complete mess. Crocker and I don't even get alone 
but he's completely right. This is what you are up against.

> yourself of the processes used to report problems with an RFC.

I wasn't paying attention to it. This entire thread is about getting 
community feedback. Either you want that or you don't. My point is that 
there is a culture that snarls at that feedback after the fact, and if 
you truly want constructive feedback you need to address that. And I 
have no clue what the processes are. Why should I? I only cursorily pay 
attention to IETF stuff these days. Is that to say that you don't give a 
shit about somebody who looked at something with fresh eyes and was like 
wtf? It's like Pete Resnick dismissing me because I didn't properly 
escalate things. are you serious? all i'm trying to do is bring 
something up and you are bureaucratically disqualify it because i didn't 
check off the right forms? you deserve what you get in that case.

> appropriately, even if you don't respond directly.
The author was a fool and flamed out soon after for different reasons. I 
was not vitriolic but it was an "attack" in the security sense against a 
security protocol. It has still not been addressed and i wouldn't be 
shocked that it has been exploited in the wild a million times over. 
That's what you are actually up against with this problem. Engineering 
prima donnas who feel attacked personally and use their stature to 
discount people with clue.

> So what you're saying is that only drama queens avail themselves of 
> the processes put in place to deal with exactly the isues you say you 
> had?

What processes? 99.9999999% of people are not encultured in IETF 
process. If you want casual people to be able to have a say about "hey, 
something is wrong here!" you need to accommodate their lack of clue 
about process. Otherwise you're just preaching to the echo chamber.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Oct 2020 18:26:03 -0700

PS: i hope that this doesn't turn into a prosecution of whether my 
examples are right or wrong because that utterly misses the point. The 
issue here is that working groups are tribalistic and people who upset 
that tribalism are the enemy. until you deal with that problem, nothing 
will happen.

Mike

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2020 11:33:41 +0100

Hi Roman,

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

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?

Eliot

Eliot

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 28 Oct 2020 14:53:30 +0000

Hi Eliot!

Sent: Wednesday, October 28, 2020 6:34 AM

Hi Roman,

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

Hi Eliot!

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.

[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: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 08:24:32 -0700

On 10/28/20 3:33 AM, Eliot Lear wrote:
>> [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”.
>
>     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.
>
>
This makes an assumption that the authors will be receptive to the 
vulnerability. My two experiences was that they were not. That hopefully 
is not universal, but not considering the tendency toward the "i know 
this, who are you?" reaction is to my mind one of the key problems here. 
The other problem is that somebody off the street is not going to know 
arcane IETF process mechanisms which can be wielded as another cudgel to 
make that reporter go away. That just got used on me yesterday and is 
perfectly timely: why didn't i follow process XYZ? because i don't know 
anything about process XYZ, and by the time I understand process XYZ 
i've already lost interest because i didn't sign up for a protracted 
bureaucratic fight. that and i have no stake in the outcome beyond just 
being interested or a user; if you make me have to fight for it, you've 
lost me.

The thing about security flaws in particular is they can be very subtle 
and hard to explain. It took me several readings of the DNS Race flaw to 
get the jist of it years ago, and that was written up by Vixie after the 
fact to explain it. The front line is going to be considerably messier 
since the reporter is not likely an expert in every aspect of the 
protocol and may get some things right and some things wrong. The wrong 
things can then be used to dismiss the problem wholesale, especially 
with the authors who have built in bias.

Don't a lot of working groups have security area liasons these days? 
People who don't have a stake in the outcome, per se? Maybe that's where 
you want to route this.

Mike

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 28 Oct 2020 16:25:34 +0100

> I am not sure what you are trying to say.  That it's hard to determine where the fault is sometimes?  I don't think anyone disagrees with that.

I have seen in the past and still a lot of resistance in standards track work to
go beyond a mathematical proveable change of packets on a physical long enough
wire. In discussions with past ADs, this has even gone as far as examples of "protocols"
between two (possibly different vendor sourced) software components within a single box as
being something not appropriately called standards protocol work for the IETF. Not
sure if you remember the history of not allowing standardization of APIs, and
only fairly recently having seen that changing.

So, i am concerned about dogmatic restrictions on what can and can not be called
"protocol" wrt. vulnerabilities, and hence i would strongly suggest not to use
it in the name.

> I worry about something like "[email-masked]" becoming swamped with implementation issues, but I would support this if we agreed it was a two-year experiment or something.

Too much success ? We are not paying money, so why the fear ? Any similar
problems in other places ?

But of course: How could we ever start something like this (that we are unfamiliar with)
without calling it experimental. Same goes also for what is already proposed by Roman.

> Patents (at least in the US) typically have an "escape clause" near the beginning, often written like "As will be readily obvious to one familiar with the field"  So I see the same parallel to stan…

Except those who develop product.

IMHO my one example is an ongoingly unsolved problem: how to dynamically manage
limited resources in routers amongst different usrs of such resources. There are no
tools to predict memory utilization for routers, so you can not even build a simulation
of a network and validate upfront that it will run without memory problems.

Just had a nice pondering about millions of dollars of outages regularily being fined
for network failures where live&death services are running over (911). Try to figure
out what type of network and operational design you need to proactively avoid
such fines in the future (and the associated loss of life of such
services failing). And that is in the absence of evil attackers, think about
how much harder this becomes when attackers are present.

Everything is easy when worst case a service can just fail, and the worst outcome is
that people have to read a book instead of streaming a movie.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2020 16:27:44 +0100

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

Sure, but keep in mine your readership.  Don’t overprocess them, as we say in NJ.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Oct 2020 15:37:00 +0000

Overloading the people who will be filtering the emails.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 08:42:19 -0700

> Overloading the people who will be filtering the emails.
Isn't overloading filtering of implementation questions signal in and of 
itself? if a particular protocol is generating lots of implementation 
questions, that's could be telling you it is underspecified. but ietf is 
not the first place i'd think to come to with implementation issues. 
stackoverflow, etc is where i'd head first.

Mike

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 28 Oct 2020 15:51:24 +0000

Hi Mike!

From: ietf <[email-masked]> On Behalf Of Michael Thomas
Sent: Wednesday, October 28, 2020 11:25 AM
To: [email-masked]
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Eliot!

This makes an assumption that the authors will be receptive to the vulnerability. My two experiences was that they were not. That hopefully is not universal, but not considering the tendency toward the "i know this, who are you?" reaction is to my mind one of the key problems here. The other problem is that somebody off the street is not going to know arcane IETF process mechanisms which can be wielded as another cudgel to make that reporter go away. That just got used on me yesterday and is perfectly timely: why didn't i follow process XYZ? because i don't know anything about process XYZ, and by the time I understand process XYZ i've already lost interest because i didn't sign up for a protracted bureaucratic fight. that and i have no stake in the outcome beyond just being interested or a user; if you make me have to fight for it, you've lost me.

[Roman] I do not believe the proposal or (defending Eliot’s) language above makes this assumption, unless you are specifically reacting to the words “we very much welcome your contribution.” This proposal will not and isn’t intended to address authors and WG being willing to accept feedback from security researchers.  This approach to vulnerability validation and remediation certainly a crucial issue, but a bit distinct from providing clearer guidance on reporting.  That said, there is definitely interplay between poorly handled validation/remediation process (e.g., untimely, unappreciative, not curious, hostile) to future willingness to report.

[Roman] As I’ve noted in previous responses, I don’t dispute that our processes are elaborate. I’m sure we can further optimize the reporting, validation and remediation processes.  However, this proposal is not focused on defining such new processes and is less ambitiously just trying to document the current state of affairs.  Toerless articulated that based on this discussion there is likely continued appetite to have this conversation beyond providing words on the website to describe how things work now.  We likely need another mailing list to continue this conversation.

The thing about security flaws in particular is they can be very subtle and hard to explain. It took me several readings of the DNS Race flaw to get the jist of it years ago, and that was written up by Vixie after the fact to explain it. The front line is going to be considerably messier since the reporter is not likely an expert in every aspect of the protocol and may get some things right and some things wrong. The wrong things can then be used to dismiss the problem wholesale, especially with the authors who have built in bias.

[Roman] Completely agree.  IMO, that’s why relying on a lightly staff triage alias might not dramatically improve the state of affairs.  The deep expertise is going to be in the original WG or follow-on groups.  However, this routing function to get the information to the right place is still a different issue than the validation process of this vulnerability (agreeing it is actually an issue).

Don't a lot of working groups have security area liasons these days? People who don't have a stake in the outcome, per se? Maybe that's where you want to route this.

[Roman] To my knowledge, formal security area liaisons are not common practice across WG, unless explicitly requested.  I would characterize such formal arrangements as fairly rare.  More common are requests for early Security Directorate (SECDIR) reviews and trying to entice those with security experience to participate in WGs that feel they need that review.  Likewise, there has been an informal push in recent years to include language related to security in charters (which may have helped only a little bit in identifying concerns and need for help early in a work’s lifecycle).

Regards,

Roman

Mike

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 28 Oct 2020 17:03:00 +0100

> To be clear, this list isn't intended to handle actual vulnerability information, but to discuss the processes by which the IETF might want to handle it, right?

Incident independent process/policies/... is the simple part, but:

First order of business: Something that has the opportunity to create long threads not of interest to the whole community should have a better place than [email-masked]

Second order of business: If/when there is a better place, such as a particular protocol WG mailing list to discuss how to handle a specific incident then it should of course go there.

Aka: i think i am pointing out that there will be aspects of incidents that
should want to be discussed in public which may not have a feasible mailing list.
Where do you think those should be discussed ?

Given our (IETF) age, i would fear there can be
many day 1 issues in stuff (protocols ;-) where WGs have long been disbanded.

Of course we can try to see if pushing those discuss to the appropriate
area(dispatch) mailing lists would be good, or some appropriate successor
WG mailing list. I would just not be too dogmatc with "sorry, we have no
place to disscuss your problem, go away", when we do not have any other better
place.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2020 17:20:51 +0100

Hi Michael,

> On 28 Oct 2020, at 16:24, Michael Thomas <[email-masked]> wrote:
> 
> 
> 
>>> On 27 Oct 2020, at 20:06, Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Eliot!
>>>  
> This makes an assumption that the authors will be receptive to the vulnerability. My two experiences was that they were not.
> 

Let’s accept that this does indeed happen for two reasons:

The report is not a protocol vulnerability, but an implementation vulnerability or a misunderstanding.
The report is a protocol vulnerability and the WG has some cultural issue that needs to be overcome.

On the first point, discussion will sort it quickly, I hope.  On the second point, it’s just something to work on, and work on it we as a community should.  Security researchers are indeed here to help, and we just have to reinforce that at every turn.  It is sometimes hard to draw the distinction between an implementation bug and a protocol bug, particularly if the protocol is in some way underspecified.  But to this point:
> That hopefully is not universal, but not considering the tendency toward the "i know this, who are you?" reaction is to my mind one of the key problems here. The other problem is that somebody off the street is not going to know arcane IETF process mechanisms which can be wielded as another cudgel to make that reporter go away. That just got used on me yesterday and is perfectly timely: why didn't i follow process XYZ? because i don't know anything about process XYZ, and by the time I understand process XYZ i've already lost interest because i didn't sign up for a protracted bureaucratic fight. that and i have no stake in the outcome beyond just being interested or a user; if you make me have to fight for it, you've lost me.
> 

Yes.  And what I am getting at is a little bit of hand holding on our side for, as I said, people who don’t want to play “Inside Baseball” could be very useful to this community.

> The thing about security flaws in particular is they can be very subtle and hard to explain. It took me several readings of the DNS Race flaw to get the jist of it years ago, and that was written u…

And that’s something cultural to work on.

> Don't a lot of working groups have security area liasons these days? People who don't have a stake in the outcome, per se? Maybe that's where you want to route this.

So long as the liaisons aren’t the only ones who are routed to, having someone who can facilitate a conversation is of course only goodness, but they cannot gate.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 09:23:31 -0700

On 10/28/20 8:51 AM, Roman Danyliw wrote:
>
> [Roman] I do not believe the proposal or (defending Eliot’s) language 
> above makes this assumption, unless you are specifically reacting to 
> the words “we very much welcome your contribution.” This proposal will 
> not and isn’t intended to address authors and WG being willing to 
> accept feedback from security researchers.  This approach to 
> vulnerability validation and remediation certainly a crucial issue, 
> but a bit distinct from providing clearer guidance on reporting.  That 
> said, there is definitely interplay between poorly handled 
> validation/remediation process (e.g., untimely, unappreciative, not 
> curious, hostile) to future willingness to report.
>

Heh, yeah, "we very much welcome..." is painting a rosier picture than 
they are likely to get :)

> The thing about security flaws in particular is they can be very 
> subtle and hard to explain. It took me several readings of the DNS 
> Race flaw to get the jist of it years ago, and that was written up by 
> Vixie after the fact to explain it. The front line is going to be 
> considerably messier since the reporter is not likely an expert in 
> every aspect of the protocol and may get some things right and some 
> things wrong. The wrong things can then be used to dismiss the problem 
> wholesale, especially with the authors who have built in bias.
>
> [Roman] Completely agree.  IMO, that’s why relying on a lightly staff 
> triage alias might not dramatically improve the state of affairs.  The 
> deep expertise is going to be in the original WG or follow-on groups.  
> However, this routing function to get the information to the right 
> place is still a different issue than the validation process of this 
> vulnerability (agreeing it is actually an issue).
>
Yeah, I completely agree that it's the working group that ultimately 
must agree and often figure out the fix assuming that there isn't an 
obvious one.

> People who don't have a stake in the outcome, per se? Maybe that's 
> where you want to route this.
>
> [Roman] To my knowledge, formal security area liaisons are not common 
> practice across WG, unless explicitly requested. I would characterize 
> such formal arrangements as fairly rare.  More common are requests for 
> early Security Directorate (SECDIR) reviews and trying to entice those 
> with security experience to participate in WGs that feel they need 
> that review.  Likewise, there has been an informal push in recent 
> years to include language related to security in charters (which may 
> have helped only a little bit in identifying concerns and need for 
> help early in a work’s lifecycle).
>

I seem to recall seeing security area reviews as the document is winding 
toward last call, but it's been a long time since I've really 
participated more than just cursorily. Part of why I chimed in is 
because i'm part of the outside-looking-in kind of crowd this seems to 
be addressing. I probably know more than your average security 
researcher about ietf process, culture etc, but it's not my $DAYJOB by 
any means and i'm pretty clueless about process archana.

The other part of this is that in my two experiences, it wasn't THIS IS 
WRONG YOU MUST FIX!!! It was "is there a problem here? can somebody 
explain to me why it isn't?" I expect that most credible submissions are 
going to be more like the latter than the former, but even those were 
met with either hostility or indifference. Assuming it's been filtered 
to being a credible concern, it seems to me that it ought to be 
independently validated (or not), and better with somebody who doesn't 
have a stake in the rfc (authors, participants) who aren't eager to open 
pandora's box. At the point somebody with known clue can vouch that 
there's a good probability there's some there there, it become much 
harder for the working group and authors to ignore.

Mike

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 28 Oct 2020 11:42:05 -0500

On 27 Oct 2020, at 16:16, Michael Thomas wrote:

> Why on earth would I want to be a drama queen? Especially since I had 
> no dog in either fight?

The fact that you think invoking them makes you a "drama queen" means 
that you are part of the problem. And the idea that if you "don't have a 
dog in the fight" means that you shouldn't fully participate (including 
using the pushback mechanisms we have), you're not understanding what 
the IETF is supposed to be about: We have plenary meetings and Last 
Calls and the like so that groups can get cross-area and outside 
feedback. Failure to call out problems simply because you're not a 
primary player is exacerbating the cultural problem you claim to see.

> happened. They wrote my concern into the security requirements with 
> like a one sentence dismissal and everybody ignored it.

And you didn't follow up with the chair or AD when that happened?

> exactly the wrong way to foster that.

Well, let's be clear here: The original thread was about how people who 
are outside of the IETF community can communicate protocol 
vulnerabilities. Your original response was "isn't the basic problem is 
that working groups don't want to hear criticism or take it seriously?" 
and then gave examples of your recent experiences dealing with feedback 
not being taken by WGs. But you are a regular IETF participant, insofar 
as you're subscribed to the IETF list and are participating (however 
much) by directly communicating concerns to WGs. I was addressing your 
comments, not the kinds of problems that a complete outsider would run 
into.

> In OAUTH's case I did talk to Barry. For STIR after seeing what they 
> did to Crocker at last call it was apparent that it would fall on deaf 
> ears so why bother?

Because everyone not bothering actually makes the problem worse.

> I did bring it up my concern on their mailing list before I read the 
> archives, but crickets.

At which point you should have gone to the chair. If a mailing list is 
misbehaving (which includes ignoring comments), that's a failure on the 
part of the chair and needs to be dealt with.

> The flip side of this that nobody wants to be seen as an insane 
> Casandra in case you are actually wrong.

Nobody who says, "I think there may be a serious problem here. This 
protocol does X, Y, and Z, and those appear to be serious security 
vulnerabilities. Am I off the mark here?" gets seen as an insane 
Casandra. On the other hand, if someone comes in saying, "This protocol 
is a complete mess because of X, Y, and Z. WTF?", yeah, they might be so 
labeled. On the other hand, someone like that strikes me as someone who 
doesn't care about such labels.

> needs to account for that.

The problem you're identifying is fixed by IETF participants pushing 
back on such behavior using the mechanisms we have in place to do so.

On 27 Oct 2020, at 20:14, Michael Thomas wrote:

> I said that most of Dave's problems were ignored and that there was a 
> lot of snarling about it being brought up in last call. Peterson in 
> particular impugned Crocker for that, as if last call was a bad time 
> for comments.

It is always the case that late comments, particularly ones that require 
substantial changes to address, will always be a bummer and, being human 
beings, sometimes cause grumpiness. But our processes are designed to 
deal with such things, and if they are being invoked appropriately or 
otherwise being ignored, that's a problem.

> That was well before I saw Crocker's comments.

So the correct moves for an IETF participant in such a situation are to 
do one of the following: (1) Bring the concerns up on the list and see 
if the WG can address them; (2) If the problems are individual points in 
the document that are correctable, file one or more errata; (3) If there 
is a serious flaw, start the appeal process for the case where "the 
Working Group has made an incorrect technical choice which places the 
quality and/or integrity of the Working Group's product(s) in 
significant jeopardy." Yes, that process is normally used for 
pre-publication, but I see no reason it can't be instantiated for 
post-publication. Resolutions could be the IESG chartering new work to 
correct the problem or adding a work item to a still existing WG, the 
IAB deciding to publish a document describing the problem, etc.

I will point out however that "I would have done this completely 
differently" or even "this is an architectural mess" are not valid 
reasons to make a change: Internet email is arguably an architectural 
mess compared to X.400, but deployment and successful interoperation 
tend to be overriding in IETF discussions.

> It took me months to get answers of what in hell was going on. [...] 
> This is what you are up against.

I'm still trying to figure out what you in particular are up against.

> My point is that there is a culture that snarls at that feedback after 
> the fact...

Look, as I said above, we are human beings in the IETF, and people will 
sometimes react poorly to feedback. (Again, I'm speaking generally; I 
don't know what actually happened in the cases you pointed out.) But 
when this happens completely internally to the IETF, it is incumbent 
upon participants to pull the levers we've got to correct those 
problems, because failure to do so will absolutely develop a culture of 
poor handling of feedback, both internally and externally. When a 
regular IETF participant complains about outcomes but has never used the 
procedures we have for handling problems, that person is part of the 
problem.

> ...and if you truly want constructive feedback you need to address 
> that.

Who is this "you" you speak of?

> And I have no clue what the processes are. Why should I? I only 
> cursorily pay attention to IETF.
> stuff these days.

Sorry Michael. I count 83 messages from you in the past year in the IETF 
mail archives. You don't get to claim "drive by" status. You are an IETF 
participant. At this point, you should at least know what RFC 2026 is 
and have a passing understanding of our processes. I'm certainly bummed 
by Rich's comment that the conflict resolution process is not mentioned 
in the newcomer's orientation; that seems like a gaping hole to fix and 
I'll try to be part of fixing it. But if you're going to participate as 
you have been, you should know some of this stuff, or at least be able 
to ask about it when need be.

> Is that to say that you don't give a shit about somebody who looked at 
> something with fresh eyes and was
> like wtf?

Nonsense. We get feedback like that all the time. Sometimes, that 
feedback is good and we take it on. Sometimes that feedback is nonsense 
and we try to respond respectfully and ignore it. Sometimes, due to the 
grumpiness of the sender or even of the receiver, that feedback can get 
inappropriately. It's all of our collective responsibilities to make 
sure that is corrected.

> It's like Pete Resnick dismissing me because I didn't properly 
> escalate things.

I'm not dismissing you. I'm saying you haven't made your case. You said 
there is this systemic cultural problem, yet you are part of the culture 
and haven't used the mechanisms we have in place to deal with the 
problems you have described. If you were an outsider, I wouldn't have 
pointed you to those procedures if you had a complaint; I would have 
simply helped you find the right person to talk and helped you address 
the problem. But you're not an outsider. You are an IETF participant. 
Take responsibility for changing the things that you can and do your 
part.

> 99.9999999% of people are not encultured in IETF process. If you want 
> casual people to be able to have a say about "hey, something is wrong 
> here!" you need to accommodate their lack of clue about process.

Yeah, absolutely, but my point is that this isn't you or the incidents 
you identified. You identified internal IETF participants (yourself 
included) not being listened to. If that's the case, you should have 
known enough to use the processes. The original thread is absolutely 
about how to get the comments of external folks into the mix. But that's 
not what you've been talking about.

On 27 Oct 2020, at 20:26, Michael Thomas wrote:

> examples are right or wrong because that utterly misses the point.

Totally agreed.

> The issue here is that working groups are tribalistic and people who 
> upset that tribalism are the enemy. until you
> deal with that problem, nothing will happen.

Again, the "you" you mention includes you, Michael. You don't get to 
push this out as if you are not part of the community. And the way you 
individually can address this kind of problem is to actually use the 
mechanisms we have in place to do so.

pr

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 09:45:00 -0700

On 10/28/20 9:20 AM, Eliot Lear wrote:

>> That hopefully is not universal, but not considering the tendency 
>> toward the "i know this, who are you?" reaction is to my mind one of 
>> the key problems here. The other problem is that somebody off the 
>> street is not going to know arcane IETF process mechanisms which can 
>> be wielded as another cudgel to make that reporter go away. That just 
>> got used on me yesterday and is perfectly timely: why didn't i follow 
>> process XYZ? because i don't know anything about process XYZ, and by 
>> the time I understand process XYZ i've already lost interest because 
>> i didn't sign up for a protracted bureaucratic fight. that and i have 
>> no stake in the outcome beyond just being interested or a user; if 
>> you make me have to fight for it, you've lost me.
>>
>
> Yes.  And what I am getting at is a little bit of hand holding on our 
> side for, as I said, people who don’t want to play “Inside Baseball” 
> could be very useful to this community.
>
What I suggested elsewhere is that maybe some sort of independent 
verification that there is a good likelihood that there is a flaw by 
somebody who knows inside ball may be helpful for things that could be 
high impact if true. The other part is that nobody but actual crackpots 
wants to be labeled one. Finding a flaw in an existing protocol that's 
been through extensive review is fraught with "am i reading this 
right?". To be jumped on as being a crackpot by authors from the outset 
is not very fun and definitely not an experience somebody who has no dog 
in the fight looks forward to. Obviously this left a really bad taste in 
my mouth but i doubt i'm the only one. Had somebody with known clue 
from, say, the security area vouched that it is problem, the author 
would have been a lot less likely to go ballistic (given that author, 
that was no guarantee though).

Mike

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2020 18:00:48 +0100

Pete,

> On 28 Oct 2020, at 17:42, Pete Resnick <[email-masked]> wrote:
> 
> The fact that you think invoking them makes you a "drama queen" means that you are part of the problem. And the idea that if you "don't have a dog in the fight" means that you shouldn't fully participate (including using the pushback mechanisms we have), you're not understanding what the IETF is supposed to be about: We have plenary meetings and Last Calls and the like so that groups can get cross-area and outside feedback. Failure to call out problems simply because you're not a primary player is exacerbating the cultural problem you claim to see.

This is where I think there may be some subtle issue, and I don’t want to make this all about Mike.  Many researchers have no equities in our organization.  They may not even have a fix available for the very problem that they have found.  We have red teams for a reason: it’s just a different muscle.  So they see their job as finished when they’ve reported.  And then they’re on to the next thing.  That’s their incentive model.  Mike just happens to care more than most, but we shouldn’t optimize around him.

Eliot

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 28 Oct 2020 12:27:17 -0500

On 28 Oct 2020, at 12:00, Eliot Lear wrote:

> This is where I think there may be some subtle issue, and I don’t 
> want to make this all about Mike.  Many researchers have no equities 
> in our organization.  They may not even have a fix available for the 
> very problem that they have found.  We have red teams for a reason: 
> it’s just a different muscle.  So they see their job as finished 
> when they’ve reported.  And then they’re on to the next thing. 
>  That’s their incentive model.  Mike just happens to care more 
> than most, but we shouldn’t optimize around him.

Lest there be any question: I completely agree with you on the above 
Eliot. The proposal on the table from the IESG that Roman posted is a 
great start into how to deal with exactly those researchers you are 
talking about, and I fully support the idea. I don't want those folks to 
have to wade through the rest of IETF process if they have no intention 
to be part of the whole kit and caboodle of WG protocol development. The 
one and only thing I was responding to was Mike's analysis of the core 
problem based on his personal experiences. He is not like one of those 
researchers in that he does participate in the IETF as a regular 
participant, and we should absolutely not be optimizing around the cases 
he's concerned with.

pr

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 10:35:43 -0700

On 10/28/20 9:42 AM, Pete Resnick wrote:
> that you are part of the problem. And the idea that if you "don't have 
> a dog in the fight" means that you shouldn't fully participate 
> (including using the pushback mechanisms we have), you're not 
> understanding what the IETF is supposed to be about: We have plenary 
> meetings and Last Calls and the like so that groups can get cross-area 
> and outside feedback. Failure to call out problems simply because 
> you're not a primary player is exacerbating the cultural problem you 
> claim to see.

You realize that this is a thread about outsiders contributing 
vulnerability clue without necessarily having any IETF knowledge here, 
right? Your hectoring is particularly ironic.

I don't go to meetings anymore. I only occasionally look at things 
rfc/groups/etc that interest me. I was never a creature of process 
archana even when I did. So I'm not a terrible proxy for somebody who is 
completely naive.

> And you didn't follow up with the chair or AD when that happened?
I just said that Barry Lieba -- wg chair -- handled the hysterical 
author well. Well, as well as could be expected.
> Well, let's be clear here: The original thread was about how people 
> who are outside of the IETF community can communicate protocol 
> vulnerabilities. Your original response was "isn't the basic problem 
> is that working groups don't want to hear criticism or take it 
> seriously?" and then gave examples of your recent experiences dealing 
> with feedback not being taken by WGs. But you are a regular IETF 
> participant, insofar as you're subscribed to the IETF list and are 
> participating (however much) by directly communicating concerns to 
> WGs. I was addressing your comments, not the kinds of problems that a 
> complete outsider would run into.
I'm mostly an outsider these days. So I'm bringing the perspective of 
somebody who knows some of the process that I wouldn't need the kind of 
guidance being hatched here, but have been on the receiving end of where 
it goes once routed. I imagine that people who also got the same 
treatment are not going to bitch about it on the ietf list because... 
they don't even know about it, and don't care enough about the meta problem.
> misbehaving (which includes ignoring comments), that's a failure on 
> the part of the chair and needs to be dealt with.
I could have done that, but after reading the archives made the 
calculation that it was a waste of time. Frankly the security flaw I 
found is probably the least of its worries. It is so underspecified that 
apparently I can use gopher: or ftp: method in the URI that fetches 
certs. That is the level of carelessness and underspecification we're 
talking about. So I did what any sane person would at that point: 
"You're on your own, son".
> Casandra. On the other hand, if someone comes in saying, "This 
> protocol is a complete mess because of X, Y, and Z. WTF?", yeah, they 
> might be so labeled. On the other hand, someone like that strikes me 
> as someone who doesn't care about such labels.
Uh, living proof right here. I'm willing to believe that it's uncommon 
though because that particular author was particularly egregious. But 
the entire thing turned into a "it's not a problem because it's not 
fixable" wtf twilight zone.
> It is always the case that late comments, particularly ones that 
> require substantial changes to address, will always be a bummer and, 
> being human beings, sometimes cause grumpiness. But our processes are 
> designed to deal with such things, and if they are being invoked 
> appropriately or otherwise being ignored, that's a problem.
What exactly is the alternative? I mean that is what last call is for, 
right? If I don't have a lot of involvement with something but am 
interested in the outcome, that is the time that I'm going to read it 
over and see if there are problems. In that particular case, there were 
so many that the comments it was pretty much a novel. That doesn't bode 
well especially given who gave the feedback. I scanned it over afterward 
and eyeballing it maybe 10% of the comments were incorporated. A lot of 
them were stylistic, but a lot of the substantive ones didn't lead to 
any changes in the document.
> So the correct moves for an IETF participant in such a situation are 
> to do one of the following: (1) Bring the concerns up on the list and 
> see if the WG can address them; (2) If the problems are individual 
> points in the document that are correctable, file one or more errata; 
> (3) If there is a serious flaw, start the appeal process for the case 
> where "the Working Group has made an incorrect technical choice which 
> places the quality and/or integrity of the Working Group's product(s) 
> in significant jeopardy." Yes, that process is normally used for 
On the list I was only interested in a couple of things: a potential 
security flaw that I found, and whether STIR covered the 
sip:[email-masked] case. The first got ignored, the second got discussed 
quite a bit but it's still not entirely clear whether it does or doesn't 
which is its own kind of flaw. As I said, I just casually participate in 
things that interest me and then go back into hibernation. So I'm sort 
of a maybe more process clueful type of person this thread is about. I'm 
definitely not interested working some long process to prove a point. 
Too much work, too little gain.
> tend to be overriding in IETF discussions.
I made no architectural arguments, though I do have opinions not 
expressed. Just the quality of the document and potential security problems.
>
> Sorry Michael. I count 83 messages from you in the past year in the 
> IETF mail archives. You don't get to claim "drive by" status. You are 
> an IETF participant. At this point, you should at least know what RFC 
> 2026 is and have a passing understanding of our processes. I'm 
> certainly bummed by Rich's comment that the conflict resolution 
> process is not mentioned in the newcomer's orientation; that seems 
> like a gaping hole to fix and I'll try to be part of fixing it. But if 
> you're going to participate as you have been, you should know some of 
> this stuff, or at least be able to ask about it when need be.
Look at the years before that. It's been very sporadic since I left 
Cisco 12 years ago.
>
>> Is that to say that you don't give a shit about somebody who looked 
>> at something with fresh eyes and was
>> like wtf?
>
> feedback is good and we take it on. Sometimes that feedback is 
> nonsense and we try to respond respectfully and ignore it. Sometimes, 
> due to the grumpiness of the sender or even of the receiver, that 
> feedback can get inappropriately. It's all of our collective 
> responsibilities to make sure that is corrected.
>
> I'm not dismissing you. I'm saying you haven't made your case. You 
> said there is this systemic cultural problem, yet you are part of the 
> culture and haven't used the mechanisms we have in place to deal with 
> the problems you have described. If you were an outsider, I wouldn't 
> have pointed you to those procedures if you had a complaint; I would 
> have simply helped you find the right person to talk and helped you 
> address the problem. But you're not an outsider. You are an IETF 
> participant. Take responsibility for changing the things that you can 
> and do your part. The issue here is that working groups are 
> tribalistic and people who upset that tribalism are the enemy. until you

Hence why I've responded. yes, it should be we but i don't feel entirely 
we these days. IETF does allow for this sort of meta state, which is 
maybe one of its charms.

Mike

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 28 Oct 2020 18:39:13 +0100

Eliot, *:

I am not even parsing all the things you wrote below, i am sure they are right.

To me they are be another proof point that at this stage IETF has
accumulated enough processes, twist and complications that one of the top
things to think about even bringing outsiders more into the IETF not only
effectively reporting but maybe helping to take steps towards resolving security issues
is to have some form of "shepherding" through he process. 

To that extend, it would be good if even the "reporting" mail alias would
not be imited to a secret small group of participants but a broader set
of IETF participants, especially those who would volunteer to help
spehpherding the process.

Even the writeup is longer than i have seen on any other incident report web page
of other organizations.

Cheers
    Toerless

On Wed, Oct 28, 2020 at 06:00:48PM +0100, Eliot Lear wrote:
> This is where I think there may be some subtle issue, and I don???t want to make this all about Mike.  Many researchers have no equities in our organization.  They may not even have a fix available for the very problem that they have found.  We have red teams for a reason: it???s just a different muscle.  So they see their job as finished when they???ve reported.  And then they???re on to the next thing.  That???s their incentive model.  Mike just happens to care more than most, but we shouldn???t optimize around him.
> 
> Eliot

-- 
---
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 10:42:58 -0700

On 10/28/20 10:27 AM, Pete Resnick wrote:
>> it’s just a different muscle.  So they see their job as finished when 
>> they’ve reported.  And then they’re on to the next thing.  That’s 
>> their incentive model.  Mike just happens to care more than most, but 
>> we shouldn’t optimize around him.
>
> talking about, and I fully support the idea. I don't want those folks 
> to have to wade through the rest of IETF process if they have no 
> intention to be part of the whole kit and caboodle of WG protocol 
> development. The one and only thing I was responding to was Mike's 
> analysis of the core problem based on his personal experiences. He is 
> not like one of those researchers in that he does participate in the 
> IETF as a regular participant, and we should absolutely not be 
> optimizing around the cases he's concerned with.
>
As I mentioned earlier, security issues can be very subtle and not easy 
to explain or understand. Lobbing a write-only report over the wall is 
hardly ideal. They have every right to do that, of course, but if they 
can be coaxed to participate while it gets digested, that would be a lot 
better. And then of course, there are the cases where somebody thinks 
something might be wrong, but isn't sure of it. That more resembles me. 
Maybe I'm a unicorn though. I'll check for glitter in a bit.

Mike

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 11:31:29 -0700

Hi Mike,

> On 10/28/20 8:51 AM, Roman Danyliw wrote:
[...]
> harder for the working group and authors to ignore.

I believe that the WG chairs/ADs can and should play this role of helping
to determine whether there is a real concern.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 11:39:27 -0700

Hi Mike,

> that tribalism are the enemy. until you deal with that problem, nothing 

I don't want to prosecute your examples, and I do believe that your
examples happened roughly as you describe.  But I do want to ask whether we
might have already improved since your experiences occurred -- for example,
I am failing to find anything in the OAuth archives from you more recently
than 2012.  While the OAuth WG is not always a shining example of comity, I
can think of several recent cases where someone who is not part of the WG
mainstream comes in and attempts to raise some issues with one document or
another.  Yes, some participants ignored or tried to reject these points,
but others (myself included) did engage with the reporter to tease out
where the actual issues lie, whether there is a prerequisite for the
perceived issues that is explicitly out of scope for the work, whether the
proposed mitigation violates protocol invariants, etc.  So, I am hopeful
that the current situation is not as dire as the picture you have painted
(and we will, of course, work to improve in the future).

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 11:42:08 -0700

> needs to be well vetted by the devs, but doesn't want to wait for the 

There are several WGs where we've had extended discussions over the text to
put in a potential errata report, before the report gets submitted.

> and/or authors can sign off easily.

I don't think that errata are the definitive mechanism for potentially
controversial things or things that require intrusive changes to resolve,
but they can be an appropriate tool.  A drive-by errata report without
additional discussion is probably not going to be the most effective way to
make progress on such issues, but it can definitely be useful to have the
issue documented in an errata report, even as a revision to the RFC is
underway to fix the issue.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 11:46:51 -0700

> only fairly recently having seen that changing.

FWIW, any reluctance to standardize APIs is not universal -- RFC 1508 dates
from 1993.

-Ben

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Oct 2020 14:53:56 -0400

I hope I am missing something.
I have trouble thinking of a case where a security vulnerability in our 
work could be reasoanbly captured in an erratta that is anything other 
than "held for future update".

The errata system is not an issue tracker for RFCs.  Accepted errata are 
not supposed to be changes to the WG agreement, even if the WG got it 
wrong.  They are supposed to be cases where the words on the page do not 
say what the WG meant.  this can be a missing (or added "not", or 
verbiage so opaque that anyone not in the room can't figure out what it 
means (although most of the time the RPC catches those before RFC 
publication.)

it is not for the cases where the WG agreed on a protocol that has a 
security hole, bug, or potential misbehavior.

Heck, in the case of 8200 I have to agree with the AD that an errata was 
not the way to fix ambiguous wording that the WG agreed on, even when 
folks later came up with an interpretation that had not been considered 
by the WG.  Errata simply are not for things that change existing WG 
agreements.

Yours,
Joel

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 11:57:50 -0700

> than "held for future update".

Yes, I was assuming these errata would end up in HFDU.

-Ben

---

From: Jay Daley <[email-masked]>
Date: Thu, 29 Oct 2020 08:29:05 +1300

Eliot

> On 28/10/2020, at 11:33 PM, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi Roman,
> 

This approach appears to me to unnecessarily link the two distinct issues of a) how are the vulnerabilities reported; and b) who is going to deal with them once reported, with the result that this mechanism is significantly reduced in utility.  (I’m only going to comment on a) as b) is out of scope for me)  

To unpick this we need to consider the perspective of potential reporters and their different motivations:

1.  People who already know the IETF will already know that they can contact the appropriate WG and/or authors and so don’t need to be told that.  If they don’t have a problem with that then there’s nothing to be done, but if they believe that this approach will not work then an alternate mechanism is needed.  The text above suggests that this is not an alternative mechanism, simply an issue routing support mechanism, and so is unlikely to address that need.

2.  In my experience, vulnerability reporters who do not know the organisation they are reporting to want to know that the organisation commits to seriously consider the result, and want a simple, centralised mechanism for reporting.  People who do not know the IETF will struggle to find the appropriate WG and/or authors and so hopefully skip to the single email address, but the positioning of that has no suggestion of either commitment or seriousness and so I don’t think that meets their needs either.

To be clear, when I say "commitment" I don’t mean "I commit to fix this problem" but "I commit to ensure this problem is put before the right people and given proper consideration".

Jay

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 12:35:27 -0700

> (and we will, of course, work to improve in the future).

As I said, I'm willing to believe that that was a rather unique set of 
circumstances, and yes it was around 2012. I don't even remember why I 
took an interest to it... although I was working on some stuff that 
required OAUTH around then in a phone app and probably got me think 
about the issue. From the wg's standpoint I was a random nobody though 
Barry of course knew me. If this thread is solely to entice security 
researchers to lob papers over the wall, then sure. But as I mentioned 
earlier it would be nice to actually interact with the person who found 
it (or thinks it could be a problem) to clarify and perhaps correct some 
incorrect assumptions, etc. At worst, it might result in an errata to 
clarify what led the researcher astray, at best it results in fixes that 
might have been rejected because the wg didn't understand the paper.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Oct 2020 12:42:11 -0700

> underway to fix the issue.

Yeah, there is a massive energy bandgap between errata and revving an 
RFC. Obviously you want clue to look over the problem and find the fix, 
but the current process isn't set up to quickly rev an RFC, especially 
if it is critical from what I've seen. Maybe distinction needs to be 
drawn on errata that are not very controversial if at all, and ones that 
require protocol changes to make fixes where there are different process 
rules for each?

Mike

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2020 21:22:14 +0100

Hi Jay

> 1.  People who already know the IETF will already know that they can contact the appropriate WG and/or authors and so don’t need to be told that.  If they don’t have a problem with that then there’…

Our people have no need of any of this.  They understand our processes, and know how to maneuver them.  This document doesn’t really address them.

> 2.  In my experience, vulnerability reporters who do not know the organisation they are reporting to want to know that the organisation commits to seriously consider the result, and want a simple,…

Yes, they will struggle to find the appropriate working group.  As to positioning...

> To be clear, when I say "commitment" I don’t mean "I commit to fix this problem" but "I commit to ensure this problem is put before the right people and given proper consideration".

… PRs welcome ;-).

Eliot

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 28 Oct 2020 21:30:13 +0000

Hi!

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!
> 
> https://www.ietf.org/standards/rfcs/vulnerabilities, and then referenced from
> www.ietf.org/contact, https://www.ietf.org/standards/process/,