[RSSAC Caucus] [SPAM] Re: Security Incident Reporting and c-root incident

[David Conrad]

Robert,

On May 22, 2024, at 6:23 PM, Robert Story <rstory at ant.isi.edu> wrote:
> I can see that argument, but I can also see an argument that stale formerly
> correct data is not as big a deal as unauthorized modification to bad data.

A bit of a red herring, but I don’t think the reason the data served by a root server is wrong matters that much to “the public” when they’re looking to be informed of "any potential security incidents that might affect [the RSS’s] proper functioning”. 

> Does stale data from 1 RSO have a 'materially adverse effect' on the RSS?

We seem to be attempting to split the “materially adverse effect on the RSS” hair.

To me, this was an externally visible event that impacted the planned activities of two TLD operators. I’d note that in the last similar incident, Cogent self-reported. It is surprising to me that this would not be considered a reportable incident. Section 4.5 speaks to severity of incidents. I could see an argument that this most recent incident could be considered a lower severity, but not reporting it would seem odd to me.

> At any rate, this is exactly why the work party is trying very hard not to
> get into the details of every possible scenario and depends on the RSO(s) to
> make the call.


It is obviously impossible to list the details of every possible scenario, so I’d have assumed their would be guidelines to help inform which incidents should be reported, e.g., “was the incident externally visible”, “did the incident result in sustained resolution failure”, etc.  More generally, I worry that depending on self reporting of potentially embarrassing incidents won’t be particularly supportive of goal 5 of the SOW (“5. Maintain/improve confidence in the RSS by providing incident reporting.”) if stuff that is externally visible isn’t reported on.

Regards,
-drc