Subject: Re: [Model-t] (meta) Trust, and threat vs vulnerability models

From: Robin Wilton <[email-masked]>
Date: Fri, 14 Feb 2020 17:52:51 +0000

As promised, here's an attempt to capture what I think we were edging towards in the exchange between me and Dirk. I’m hoping this will help us get to consensus about the scope and purpose of what the group will work on.

I appreciate the misgivings EKR expressed about scope, and about whether we are actually talking about anything new, here. I think that may be an inevitable consequence of framing this as a “threat” model as opposed to a vulnerability model. The former, in principle, is a non-finite list, whereas the latter can be finite... so we may be talking about a never-ending list of emerging threats, but they might all target existing vulnerabilities which are known, understood and mitigated already. Maybe the most useful goal of this group is to work out the fastest and most reliable way of telling whether or not that is the case.

So, we might formulate a question like this: "does a shift towards information-centric networking change the reasons why I should or should not trust the network to behave as I expect?"

If you change the things I rely on when I'm making a trust (or security) decision, you change the threat model. So, for instance, I used to trust intermediary network nodes because they were dumb, and therefore didn't expose a useful attack surface, but now those network nodes are doing more processing, are participating in an ICN reputation scheme, and could potentially be gamed to my detriment. They embody vulnerabilities they didn’t embody before, but which might be known and understood in other contexts. The ways in which an adversary might exploit the intermediate nodes has changed, and I should no longer rely on the reasons I used to rely on, when judging whether those nodes will behave as I (still) expect them to.

So then, in practical terms, we might want RFC authors to think as follows:

- Nodes of type x used to be dumb, but are now functionally rich; this has increased their attack surface, but the resulting vulnerabilities are still:
	- data exfiltration
	- alteration of data in motion
	- denial of service
… and we already have design patterns for mitigating those vulnerabilities from other comparable use cases…

Or…

 - Nodes of type x used to be dumb, but are now functionally rich and participate in reputation schemes that can be gamed so as to modify the network's behaviour; this gives rise to a new vulnerability:
	- manipulation of service levels
… which we have not had to mitigate before, but which could be mitigated by doing z.

I hope this is useful,
Yrs.,
Robin

> On 14 Feb 2020, at 15:31, [email-masked] wrote:
> 
> Send Model-t mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.iab.org/mailman/listinfo/model-t
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Model-t digest..."
> Today's Topics:
> 
>   1. Re: model-t webex chat - Friday Feb 14th 1600 UTC
>      (Stephen Farrell)
>   2. Materials for tonight's call (Jari Arkko)
> 
> From: Stephen Farrell <[email-masked]>
> Subject: Re: [Model-t] model-t webex chat - Friday Feb 14th 1600 UTC
> Date: 14 February 2020 at 12:45:15 GMT
> To: Jari Arkko <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> 
> Hiya,
> 
> That agenda seems fine. We can agenda-bash on
> the call as needed.
> 
> We can use this etherpad [1] for notes. If
> someone's willing to help take notes, that'd
> be great.
> 
> Cheers,
> S.
> 
> [1] https://etherpad.ietf.org/p/model-t-valentinessday
> 
> On 13/02/2020 13:17, Jari Arkko wrote:
>> How about this for agenda for tomorrow?
>> 
>> 1. Introduction (Stephen)
>> 2. Getting organised as an IAB program (Jari)
>> 3. Technical discussion (all)
>>    - analysis of threats
>>    - recommendations for threat model update
>>    - other issues
>>    - draft updates
>>      o   draft-arkko-farrell-arch-model-t-02 (Stephen)
>> 4. Any other business
>> 
>> Jari
>> 
> <0x5AB2FAF17B172BEA.asc>
> 
> 
> From: Jari Arkko <[email-masked]>
> Subject: [Model-t] Materials for tonight's call
> Date: 14 February 2020 at 15:30:38 GMT
> To: "[email-masked]" <[email-masked]>
> 
> 
> Our main discussion item will be around drafts and people’s thoughts and issues. But for the other part, administrative, agenda, and organisation, there are a couple of slides:
> 
> 
> For the drafts that we know of:
> 
> https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-02 <https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-02>
> http://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt <http://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt>
> 
> See also some other work that’s related but maybe not directly on point in the references of the above two drafts. Other contributions & discussions of your thoughts are welcome!
> 
> Jari & Stephen
> 
> <model-t-org.pdf>
> 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Feb 2020 20:18:28 +0000

Hi Robin,

I'm not sure I'm following your argument TBH, but that
might be because I think the answer to:

On 14/02/2020 17:52, Robin Wilton wrote:
> "does a shift towards information-centric networking change the
> reasons why I should or should not trust the network to behave as I
> expect?"

...is fairly straightforwardly a "no."

Without straying too far into ICN weeds (but I am a bit,
hence the change to the subject line:-), ICN has no real
conception of confidentiality nor access control that
doesn't bring it right back to host-based networking (in
terms of risks). I guess in future someone might figure
out "pure" ICN-oriented solutions for such services, but
afaik, they've not. I think the same is also still true
for how any PKI might be used to support ICN, so even
the signed-data doesn't really change many of the risks
that much.

So I'm not clear that consideration of ICN will be that
enlightening for us.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 14 Feb 2020 12:23:13 -0800

> So I'm not clear that consideration of ICN will be that

I'm not super-versed in ICN, but it seems like it would be more of an
object security model than a connection-oriented one, so it might become
hard to know that you have received the latest information of a given kind.

-Ben

---

From: Robin Wilton <[email-masked]>
Date: Mon, 17 Feb 2020 12:39:07 +0000

Thanks, both... just for clarity, my question/point wasn’t about ICN per se.
It was an attempt to find a (maybe poor) example of an innovation that changes the function of network nodes, increases the attack surface, and therefore potentially invalidates some of the reasons why I might previously have trusted the network to behave in a particular way.

Here’s the hypothetical I was trying to explore: maybe I previously trusted intermediate nodes not to prioritise other users’ traffic over mine, because those nodes were too dumb to do so. However, let’s suppose that an intermediate node now starts to make “reputational” judgements about the behaviour of other nodes, and starts to prioritise particular routes for some kinds of traffic. That potentially creates a situation in which an adversary could manipulate the “reputation” data so as to influence the node’s decisions about prioritisation, in ways that weren’t previously an option.

Like I say, this isn’t so much about whether ICN makes that possible (though I’ve heard something similar described as an R&D idea); it’s about whether increased functionality at intermediate nodes (as opposed to endpoints) materially changes the threat model.

Hope this helps,
Robin

________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Friday, February 14, 2020 8:23:13 PM
To: Stephen Farrell <[email-masked]>
Cc: Robin Wilton <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Model-t] ICN as an example (was: Re: (meta) Trust, and threat vs vulnerability models)

-Ben