Transcript Trust and the design of applications

Architecture from the
top down
David D. Clark
MIT CSAIL
April, 2009
What does that mean?


Reasoning from requirements to
mechanism.
Reasoning from the application down to
the supporting mechanisms.

Applications are the driver, after all.
In the early days…

We did not give much guidance to application
designers.


Did not seem to be part of the architecture



Was not a reliable byte stream and the DNS enough?
No constraints on what the designer did.
Is not architecture a form of constraint?
Our view of application design was simple.


Two party interaction.
(Except email)
As things evolved

Email came down with spam and viruses.


The Web came down with caches, proxies and
Akamai.



Reminder of adverse interests.
Reminder of performance concerns.
Structures generally got more complex.
Many of the issues that plague users arise at the
application layer.


Security issues.
Inexplicable failure modes.
Today and looking forward

Applications are often very complex.

Composed of lots of servers and services.


Web 2.0, mashups, cloud computing, huge server
farms and the likes.
Their structure reflects the economic (and
other) incentives of the designers.


We need to study the “architecture of control”.
Application designer as power broker?
Issues to consider










Security
Availability and resilience
Better management
Economic viability
Longevity
Meet society’s needs
Support for tomorrow’s computing
Exploit tomorrow’s networking
Support tomorrow’s applications
Fit for purpose (it works…)
Thesis I:





Applications will need to tailor their behavior to different
operating contexts.
Future applications will offer a range of “operating
modes” or “communication patterns”.
By shifting from one pattern to another depending on
context and requirements, participants will be able to
adapt application behavior to their needs.
Control over the selected pattern will be a point of
control and tussle.
The job of the network is to facilitate and enforce the
patterns.
Security--general framework



General systems like PCs will always have
residual vulnerabilities, and will be targets of
opportunity for application-level infiltration.
We can build smaller, fixed function devices that
are much more secure.
Applications can achieve higher overall security
be moving security-critical functions to these
“helper” nodes.

This behavior will require the involvement of
applications.
Security--specific examples

Confidentiality and integrity during communication.


Shall we encrypt?
Information security


Is transport responsible for information integrity?
How does an application maintain info integrity?





Block unused apps (firewalls)
Validate identity (if not a public server)
Inspect contents (viruses, malware, etc.)
Exfiltration


How do we track provenance?
Infiltration


A small piece of a much bigger problem: see Clark-Wilson paper.
Validate identity and authorization
Availability (see next slide)
Availability (theory of)


Replication of servers/services.
Detection of failures




Failover to different instance



Who can direct or trigger failover? End-nodes?
Reporting and correction of failure


Perhaps obvious if “fail-stop”.
Less obvious if more subtle.
May occur at end-node or along the invocation chain.
We don’t often support this capability.
(Management) (see next slide)
(Security: firewall = ¬ availability, ¬diagnosis )
Management

Performance issues




Detecting and restoring failed services
Giving users clear information about
application status.


Pre-positioning content near client.
Selecting efficient instance of a service
Hiding internal structural complexity.
Making distributed apps easy to deploy,
configure and maintain.
Economics

Structure of applications reflects motivations of
designers.

Central component to maintain control


Global footprint to dominate market


Akamai
Changing model of value

Computation is commodity, data is key.


Who controls different sorts of information?
Mashups mash information, not computation.



IM, games, eBay, facebook,
Maps, social nets, reputation, identity,
(Worth asking who has advantage for different data.)
Is there a “network-network” interface for apps?
Social/regulatory considerations

Avoid “baking in” rigidity in the face of variation
in social and cultural norms.



Allow for “cultural tussle” at the app level.
Identify well-known tussles (e.g. spam-like
behavior) and design for preferred outcomes.
Deal with regulatory requirements.

Logging (IM for stock traders), wiretap



What is revealed and protected.
Anti-logging (prevent legal discovery)
Privacy issues.
Network service model



Interactive (e.g. all the parts are there at
the same time).
Staged (like email, DTN, etc.)
In-net conversion


Application-specific reformatting, etc.
Support a wide range of end-node devices
with different capabilities.
Theories of decomposition

Data-centric






Isolation of high-value information.
Regions with distinct needs for assumptions about trust.
Efficient positioning of interactive components.
Economic decomposition.
Isolation of components that require quick
upgrade/enhancement.


What I called data enclosures.
Security defenses.
Isolation of components that capture cultural norms.
(very abstract statement, I know…)
Observations

The end-node is only a small part of the picture.



Ask: who controls what is happening?


Often just the web browser.
And it is insecure.
Who has choice, who has power.
Power is expressed through:




Selection of application design alternatives
Closed protocols
Data enclosure
Control over the patterns of communication.

Who controls this? Asymmetric tussle.
Power, control and choice


Application designers can design in the
preferred range of patterns.
Initiators of operations (e.g. the invoking endpoints) can attempt to pick among these
alternatives.


The potential for choice
Network operators can control which patterns
are allowed.

In the end, topology trumps, but in the end, a blunt
instrument. The encryption escalation.
Three conclusions


These patterns transcend specific application objectives.
They apply to broad classes of applications.
Most application designers will benefit from guidance as
to how to think about and implement them.


What I have been calling design patterns.
In many cases, the factor that will determine which
pattern is preferred is assessment of which actors are
most trustworthy.


So management of trust, and by extension identity, must be
native facilities.
Trust assumptions will span applications.
Design options

Encrypt vs. clear


Validate identity/authority or not.







Separate the narratives.
Logging of actions or not.
Client choice over service.


Adds overhead, complexity
Use of “indirection nodes”
Include or strip identity/authorization info.
Control who can see such info.
Information integrity using trusted transformations.
Encourage/regulate dissemination.


Clear allows inspection, allows disclosure
Instance (facilitates DDoS) and provider-level.
Diagnose-ability or not of failures.
Thesis II:



A major determinant of which pattern or mode is used
will be the trust among the communicating parties and
the other parties relevant to the situation (e.g. the ISPs,
etc.)
Trust requires a baseline of identity.
Trust and identity will be foundational for tomorrow’s
applications.

Lots of ways to get these functions wrong.
Designing identity schemes

There is more than one way we could approach identity.

A private matter among end-nodes.


Signal of identity that is visible in the network.




E.g. encrypted or meaningless except at end points.
Surveillance cameras in cyberspace.
Facilitate both policing (perhaps) and repression.
Third-party credentials vs. continuity-based familiarity.
Revocable anonymity.

Anonymity can only be revoked by its creators.
Probably need all in different circumstances, so
architecture should not constrain.
These are not choices to be made by technologists
alone.



Need a multi-disciplinary conversation.

I am very fearful of getting this wrong.
Questions?
Two quotes from the E2E paper
“In a system that includes communications, one
usually draws a modular boundary around the
communication subsystem and defines a firm
interface between it and the rest of the system.”
“The function in question can completely and
correctly be implemented only with the
knowledge and help of the application standing
at the end points of the communication system.”
Why did we say this?


The network was and is flakey.
The end-node was a trustworthy platform on
which to depend.



Reliability checks can compensate for unreliable
network.
But today the end-node is perhaps the least
trustworthy part of the system.
Today the issue is both technical reliability and
tussle (actors with adverse interests.)

Does this eliminate the E2E argument, or motivate us
to dig deeper?
A more general form
A possible re-framing of E2E is “trust-to-trust”.
 Original: “The function in question can completely and
correctly be implemented only with the knowledge and
help of the application standing at the end points of the
communication system.”

Revised: “The function in question can completely and
correctly be implemented only with the knowledge and
help of the application standing at points where it can be
trusted to perform its job properly.”
Begs the question “trusted by whom”, and who has the
power to dictate the answer.
A final question




Do “we” trust the user.
When we do, we get peer production of content
(Wikipedia), collaborative filtering, etc. This is
seen as the wave of the future.
But do we trust the user to select among routes,
report failures in system components, and so
on?
The distinction may have to do with aggregate
behavior. How can we design applications to
harness this for all the issues I have mentioned
here?
Outline





First, a review of lots of reasons why
applications will not always work the same
way--why patterns of communication will
vary.
Briefly, a catalog of theories of
decomposition.
Comments on power and control
Evidence for the centrality of trust
Some conclusions, and an aside on E2E.