Re: [Teep] IETF 101 agenda requests

["faibish, sorin" <[e-mail]>]

David,

Thank you for your detailed clarifications. I just want to address one point within:

-----Original Message-----
From: Wheeler, David M [mailto:[e-mail]] 
Sent: Tuesday, March 27, 2018 1:37 PM
To: Dave Thaler <[e-mail]>; Benjamin Kaduk <[e-mail]>; faibish, sorin <[e-mail]>
Cc: teep <[e-mail]>; [e-mail]
Subject: RE: [Teep] IETF 101 agenda requests

> For it to not be orthogonal, one would have to argue how/why it affects the OTrP protocol itself.  

OK, let me try to present the argument :)

A TEE application, when provisioned into a device, will require certain resources of the device.
These resources will definitely include storage, RAM, and possibly some measure of CPU time.
OTrP //should// have some policy hooks that allow a device/device user/owner to define what are acceptable limits of resource consumption for a TEE application. For example, as long as a TEE app consumes less than 100MB RAM, it is OK to install (perhaps because I only have 250MB allocated to the TEE, and I don't want ALL the memory consumed by one app).

This policy should be attached to the TEE application at install time, be interpreted by the OTrP Agent, and be evaluated as an intersection of the application characteristics along with the device/platform/TEE policy.

Now, once these simple TEE app characteristics (memory, storage, CPU time) are considered, there are other characteristics that a TEE app might want/need access to. Here are some examples:
- device monotonic counter: some platforms have limits as to how often the MC can be updated, and the entire life of the MC, based on flash wear leveling. Restricting how a TEE app can use a MC is a policy decision for the device/TEE
[sf] The resources used for DDoS potential attacks are not necessarily detected as extremely different as Dave pointed in the other email yet the fact that the execution of the offending code is IMHO already a breach as the secure application was used to activate network traffic that it was trusted to be real data sent to the cloud and yet it is malicious. As Dave mentioned the amount of traffic is not very large but it is sent from many IoT devices. The problem I want to address is the trust that the "safe" application was given and due to the breach the attackers are using to generate the network packets which in my opinion is a breach of trust. There is a valid question though that Dave asks: how do we identify malicious packets not in very large amounts sent by the "trusted" application. In normal situations the application may send packets to the cloud, for example, not legitimate ones. This is the real problem of trust. 

./Sorin  

- secure key store: there may be limits to the number of keys that can be stored within the TEE in a replay protected non-volatile secure storage area. Access to this might be based on a TEE policy

- other trusted HW devices: some devices on the platform may solely be accessible inside the TEE, others might be configurable to be in the TEE or outside. And access to these devices might need to be restricted. For example, access to certain FW flash areas for secure update, access to the Safety Island on certain industrial parts, and of course access to the network, especially in a promiscuous mode.

Additionally, I might configure my device so that //certain// service providers are trusted to a level where they get access to //all// these types of special resources (I trust those service providers) and other service providers do not get any such access, or very limited access. One might argue, how can you enforce this? The TEE manifest that includes the characteristics and requirements could lie - yes, but then they would be found out, because their app is signed, and they would be banned by the TSM.

So, now back to our proposed use case:
For the DDoS application to work, it must be able to get access to the lowest packet level of the network stack, and be able to process packets at line speed. This requirement has significant draws on the capability of the TEE - available access to the network device, amount of memory consumed for packet buffers, amount of processing to keep up with packets, ...

Some TEEs may not even be //able// to provide such services. Other TEEs may restrict it.

OTrP should be able to convey, during install, the rich set of application requirements the TEE app needs to properly run, and this should be able to be interpreted against the policy and capabilities of the TEE as interpreted by the OTrP agent (or equivalent manager in the TEE). 

For this reason, I like this use case, because it represents a non-trivial application (not just an App computing pi), with interesting and complex requirements on the HW, environment, and other policy (like privacy - do I want an app that sees ALL of my network traffic and possibly be able to evaluate my network flows?) 

How should OTrP handle the communication of TEE Application requirements? What policy language is built into the protocol? Does the policy language include some privacy atoms, as well as TEE resource atoms? What other characteristics can be / should be represented by the policy language? What are the limits of policy interpretation by the OTrP agent? These, I believe are valuable questions to consider. Perhaps we get to the point that it is too complex for our first version, but I would like us to have the conversation and consider it. And then, at least, have some insight to where such a descriptive policy language might intersect with the protocol (at some point).

Thanks,
- Dave Wheeler

-----Original Message-----
From: Dave Thaler [mailto:[e-mail]]
Sent: Tuesday, March 27, 2018 9:34 AM
To: Wheeler, David M <[e-mail]>; Benjamin Kaduk <[e-mail]>; faibish, sorin <[e-mail]>
Cc: teep <[e-mail]>; [e-mail]
Subject: RE: [Teep] IETF 101 agenda requests

On slide 6 of the "Problem Statement" slides there were three use cases for Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of which one was IoT. 

The Mirai botnet attack used the REE (not a TEE) of devices to conduct attacks against an external entity.  Since TEEP is about TEE provisioning, not REE provisioning, TEEP is not directly applicable to controlling how/whether malware can be installed in the REE.

I think what David's saying is that a provisioned TEE application could have functionality to detect/mitigate something malicious that it detects an REE app is doing.  That's true, just like the TEE application could do anything else (compute pi, etc.) but we shouldn't try to enumerate every operation that a TEE application might try to do, just things that introduce requirements on OTrP.

In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (as opposed to use cases for Trusted Apps in general).
In the discussion around slide 6, we agreed that Rich Apps are largely orthogonal because they don't introduce
new requirements on the OTrP protocol.   I think Ben's saying this is similarly orthogonal.

For it to not be orthogonal, one would have to argue how/why it affects the OTrP protocol itself.  If there is such an argument, that would be a good way to continue this discussion.  If not, or if we don't know if there is, then it's orthogonal until such an argument is provided.

Dave

-----Original Message-----
From: Wheeler, David M <[e-mail]>
Sent: Tuesday, March 27, 2018 8:44 AM
To: Benjamin Kaduk <[e-mail]>; faibish, sorin <[e-mail]>
Cc: teep <[e-mail]>; Dave Thaler <[e-mail]>; [e-mail]
Subject: RE: [Teep] IETF 101 agenda requests

Ben,
I agree with you regarding the question of charter, however, I think (please correct if I misunderstand) what Sorin is proposing is to use the DDoS example as a use case to evaluate if OTrP has considered the appropriate relationships and entities within the protocol that would allow the proposed DDoS solution to be implemented.

Our charter does state that "the solution approach must take a wide range of TEE and relevant technologies" and the architecture document includes "relevant use cases." Since the DDoS proposal includes an implementation where a TEE application implements a set of filtering policies, I believe it is relevant.

I think it is a very interesting use case, since it expands beyond a simple Device-User to Service-Provider situation, and creates a more complex interaction for the application - especially the interaction of the trusted application to aspects of the device itself (i.e. filtering outgoing packets). Is our policy for accepting TEE applications rich enough (or at least extensible enough) to enable a device/user to implement controls on what applications are allowed to do, perhaps even based on the service provider installing those applications.

I believe it is in our best interest to evaluate it, and the implications of such TEE applications. We can still come to the conclusion that some aspects of supporting such a use case may be out-of-scope, but it will give us concrete information to point to regarding what is exactly out-of-scope, why it breeches our scope, and perhaps direct future additions/expansions to the protocol.

Thanks,
Dave Wheeler


-----Original Message-----
From: TEEP [mailto:[e-mail]] On Behalf Of Benjamin Kaduk
Sent: Monday, March 26, 2018 6:33 PM
To: faibish, sorin <[e-mail]>
Cc: teep <[e-mail]>; Dave Thaler <[e-mail]>; [e-mail]
Subject: Re: [Teep] IETF 101 agenda requests

On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote:
> We discussed the DDoS in Singapore and we had a presentation on the DDoS:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data
> =02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=
> 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=0
> er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk
> -kang/
> 
> So, I would like to include this usecase as a target for the WG. I 
> will write a draft related to this usecase. Thanks

Wanting it to be a target and writing a draft are both orthogonal to the question of whether the work is in-charter.  (Rechartering to include it would of course be possible, through the normal
procedure...)

-Ben

> ../Sorin
> 
> -----Original Message-----
> From: Benjamin Kaduk [mailto:[e-mail]]
> Sent: Friday, March 23, 2018 8:39 AM
> To: faibish, sorin <[e-mail]>
> Cc: Dave Thaler <[e-mail]>; teep <[e-mail]>; 
> [e-mail]
> Subject: Re: [Teep] IETF 101 agenda requests
> 
> Hi Sorin,
> 
> On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote:
> > New proposed usecase for TEEP WG.
> > 
> > Most recently the frequency and intensity of DDoS attacks from IoT devices increased with attacks almost every day. The reason of the proliferation of DDoS attacks from IoT devices is a result of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented as this would increase the cost of such devices using any security HW. In the current charter of TEEP there sre 3 usecases and I would like to add the protectioin against DDoS of IoT as a new usecase:
> 
> On a quick read of the charter, I don't see how this topic would be in scope -- am I missing something that would allow it?
> 
> Thanks,
> 
> Ben
> 
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft
> .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636577622384270342&sdata=1F4dZBFAumiRdEl7G4FYn0bO9VSzFy
> k%2BSkxW6cCfesw%3D&reserved=0

_______________________________________________
TEEP mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfesw%3D&reserved=0