Re: [arch-d] Possible new IAB program on Internet trust model evolution

> There is relatively broad agreement that the roles and trustwortiness
> of different endpoints in a protocol exchange are important
> considerations. In specific cases there may be quite different
> perspectives on the tradeoffs involved, e.g., to what extent privacy,
> information centralisation, or the needs of enterprise networks should
> be considered as the highest priority. And no doubt, other equally
> valid perspectives exist.

Actually, it's not clear to me that *any* of these are valid
things to put in a threat model. Recall what 3552 says a threat
model is:

   A THREAT MODEL describes the capabilities that an attacker is assumed
   to be able to deploy against a resource.  It should contain such
   information as the resources available to an attacker in terms of
   information, computing capability, and control of the system.  The
   purpose of a threat model is twofold.  First, we wish to identify the
   threats we are concerned with.  Second, we wish to rule some threats
   explicitly out of scope.  Nearly every security system is vulnerable
   to a sufficiently dedicated and resourceful attacker.

But none of the things you list are really part of a threat model.

Rather, they are weights one applies to various design considerations,
but that's a consideration but that's a form of analysis that happens
*after* you have a threat model, not part of the threat model itself.
For instance, I don't think anyone thinks that privacy threats (e.g.,
traffic analysis) aren't part of our threat model (and they're clearly
part of the 3552 threat model). Now, as a matter of protocol design,
we have often opted not to do much about these threats for practical
reasons, but that's a different matter.

As Brian said, the purpose of 3552 is to force protocol designers
to describe the security properties of their protocols and the purpose
the threat model section is to provide a common starting point for
that analysis. IOW, it is an essentially tutorial function So to the
extent to which an update for 3552 is needed, its purpose should be to
make clear considerations which aren't otherwise obvious from the text
in 3552. But that's not about a new threat model or about balancing
but rather about documentation.

-Ekr

On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko <jari.arkko@piuha.net> wrote:

>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this
> email.
>
> We'd like to get feedback on that idea and the text. As you may
> be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There’s also a virtual
> meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered
> to the IETF for consideration - it is not within the IAB's remit, nor
> that of an IAB program, to modify a BCP. Nonetheless, an IAB
> program offers a good venue for this work, as it perhaps allows
> for more focus on the evolving architecture aspect within this space.
>
> The plan is for the new program to be entirely open for participation,
> similar to how the current work has already been. That is, the mailing
> list is open for all interested to join, meetings are open and listed
> in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will consider this
> further in the next few weeks, so if you could take a few minutes
> to share your thoughts on this that'd be great.
>
>
> https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t
>
> Stephen & Jari
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>