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

[Jay Daley <jay@xxxxxxxx>]

Eliot

On 28/10/2020, at 11:33 PM, Eliot Lear <lear=40cisco.com@xxxxxxxxxxxxxx> 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 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

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

-- 
Jay Daley

IETF Executive Director
jay@xxxxxxxx