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

[Eliot Lear <[e-mail]>]

Hi Eric,

I appreciate your specificity.  It really helps to focus the discussion.

I would say that the world is a more complex place than it was when 3552 was written.  That is not to say that the document is out of date, but rather that it is reasonable to explore what confidentiality means in various contexts and how that relates to integrity.

Also, I do think it’s worthy addressing a slightly different threat model: when the endpoint that you purchased may be a threat to you, and whether there is something to be done about that.  I gave an example on another list of an Internet toy that has an undisclosed microphone and camera that invade’s a child’s privacy.

We discussed another case in which there needs to be auditing of train signaling systems.  And there are very complex cases involving medical devices that are probably worthy of discussion.

Does any of this require an update to 3552?  I think that would be premature to say.  But they’re probably worthy of discussion.

Eliot

> On 24 Jan 2020, at 21:03, Eric Rescorla <[e-mail]> wrote:
> 
> Brian's comments match my recollection. Specifically, we didn't think we were *defining* a threat model as much as documenting a consensus model that already existed. Incidentally, it's not clear to me what a "trust model" is. This is not a term that appears in 3552 nor is it a real term of art that I am familiar with.
> 
> Taking a step back, I remain unpersuaded that the 3552 threat model is really out of data. The two main deficiencies I have heard floated are:
> 
> 1. That it doesn't take into account traffic analysis and pervasive monitoring.
> 2. That the assumption that endpoints are uncompromised is unrealistic.
> 
> I can see some merit in the first point, but this seems to really be more a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, which means that it can observe all communications. So really what has happened is that we have a clearer picture of just how realistic that is and what you can do with that kind of access. I can see some kind of update, but again it's less about threat model than about modern examples.
> 
> As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model.
> 
> What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes.
> 
> -Ekr
> 
> 
> On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> Hi,
> 
> I'm confused. What we have in RFC3552 is very intentionally guidance for
> RFC writers on what they need to cover in their RFCs. Its specific purpose
> was to get rid of "Security considerations are not discussed in this memo."
> Its purpose was not primarily to define an abstraction like a "trust model"
> or a "threat model" (the draft charter seems a bit vague about which of those
> it means).
> 
> I really do not want to see the pragmatic purpose of RFC3552 lost in the
> effort to define these abstractions. I don't think that is the intention,
> but the text seems to imply that RFC3552 was mainly a description of a
> generic threat model, which it wasn't.
> 
> I am not against an IAB effort to analyse how the threat and trust models
> (plural) have evolved since the security workshop [RFC2316] that ultimately
> led to RFC3552. That seems like a good idea. An update of "Guidelines for
> Writing RFC Text on Security Considerations" also seems like a good idea.
> But the draft charter text seems to conflate these two separate lines of
> action.
> 
> Incidentally, while writing the above it occurred to me why the phrase
> "IAB program" has always slightly disturbed me. Really the proposal is
> a virtual IAB workshop (whereas RFC2316 came from three days in a room
> together in Murray Hill, NJ). A good idea, but not a program.
> 
> Regards
>    Brian
> 
> On 25-Jan-20 00:49, Jari Arkko 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://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md>
> > https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>
> >
> > Stephen & Jari
> >
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>
> >
> 
> --
> Model-t mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>