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

[Roman Danyliw <rdd@xxxxxxxx>]

Hi Mike!

 

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

 

 

On 10/28/20 3:33 AM, Eliot Lear wrote:

Hi Roman,

On 27 Oct 2020, at 20:06, Roman Danyliw <rdd@xxxxxxxx> wrote:

 

Hi Eliot!

 

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

 

 

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

 

 

If you believe you’ve discovered a protocol vulnerability, we very much welcome your contribution.  

You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate, in order to discuss protocol improvements to address any vulnerabilities.  If you do not know which IETF working group or mailing list to use or otherwise need help with our processes, we invite you to email “protocol-vulnerability@xxxxxxxx” 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.

[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