Re: [hrpc] from “Security Considerations” to “Threat Model Considerations”?

[Cory Francis Myers <[e-mail]>]

On Mon, Nov 06, 2023 at 08:06:27AM -0500, farzaneh badii wrote:
> I did not follow the presentation but the term "safety" is very ambiguous
> and has different meanings in different contexts and most of the time it is
> assumed that safety means cooperation with law enforcement (public safety).
> Some of my work is in the "trust and safety" field and I keep facing this
> challenge. "Threat models" will also expand the technical definition and it
> might even expand it so much that we include disinfo operation and a host
> of other non-technical ones or at least leave space for that.

I think that this expansion, including these differences and
ambiguities, is exactly what I'm advocating here.  Having to anticipate
and articulate the baseline security goals and risks of a
protocol---that is, just the ones we've been able to think about in
advance---is good for its security posture.  Shouldn't the equivalent
hold for other values and criteria too?

We might well find that there are conflicts among them.  Indeed, I'm not
persuaded that security considerations are *without* differences and
ambiguities.  My interest is in having to document them: first in order
to (have to) think and talk them through; then in order to inform
implementation, operation, and future standards work, just as the
conventional technical considerations do.

My original message preceded yesterday's dult BoF, but there's resonance
with the discussion there about testing and perhaps even measuring the
impact of a new protocol.  That suggestion was for an empirical
approach; this is for merely a theoretical and imaginative one.

This said:  Hannes, I take your "considerations sections considered
harmful" :-) caution seriously.  And, Ekr, I take for granted your
points that what I'm proposing can't happen within the IRTF and would be
unlikely to succeed in the IETF.


	--- cfm.