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

[Michael Thomas <mike@xxxxxxxx>]

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.

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

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