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

[Ted Hardie <[e-mail]>]

On Fri, Jan 24, 2020 at 12:03 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.
>

One of the changes I'm interested in seeing is a shift away from seeing
this in terms of a single communication channel, which I believe is
inherent in this text:

   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.


One of the biggest shifts in the pervasive surveillance case is that the
attacker is both likely to be present on any alternative communication
channel and likely has sufficient context over time to cross-correlate
communications.  We're moving from an omnipotent attacker to one that is
also both omnipresent and eternal.  While that may have been obvious to
those specifying RFC 3552, it is hard to read in the current document for
those who were once more naïve.   That doesn't really mean RFC 3552 is
wrong, just that explaining the implications in the current context may be
useful.

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.
>
>
Here, I think the point is really to move the IETF away from thinking in
terms of host requirements. I agree with you that there are pieces to this
that are very similar whether you think of  JS code in a sandboxed tab or
about an IoT device or about TOPS-20 device connected to an IMP.  But if
you assume that the PC running the browser hosting that tab is the unit of
analysis, you might have a very bad time.  Again, not really a change in
the threat model, but a change in the context.  This may be a way of saying
that I agree with your point below.

regards,

Ted


> 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
>>
> --
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>