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

[Bernard Aboba <[e-mail]>]

EKR said:

"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."

[BA] I agree that RFC 3552 does feel dated with respect to today's Web.  In
a number of cases, it has become clear that the term "endpoint" is too
general, and that we may need to define much more precisely what endpoint
elements (e.g. JS applications, native browser code, trusted hardware
modules, etc.) are trusted with what data.

On Fri, Jan 24, 2020 at 12:04 PM 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]> 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
>> >
>> > Stephen & Jari
>> >
>> >
>> > _______________________________________________
>> > Architecture-discuss mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>> >
>>
>> --
>> Model-t mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/model-t
>>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>