[cap-talk] Fwd: HotSec '07
erights at gmail.com
Sat Jul 7 19:20:29 EDT 2007
The Horton paper just got accepted to Hotsec (Hot Topics in Security)
2007. Referee comments below. The deadline for the final paper is
7/31. In order to address the referee's issues and stay within the 5
page limit, some cleverness will be needed. Suggestions appreciated!
---------- Forwarded message ----------
From: Trent Jaeger <tjaeger at cse.psu.edu>
Date: Jul 6, 2007 9:33 AM
Subject: HotSec '07
To: erights at gmail.com
Cc: hotsec07chair at usenix.org
On behalf of the 2007 Workshop on Hot Topics in Security (HotSec07)
program committee, I am pleased to invite you and one other of your
coauthors (if applicable) to participate in the the workshop, to be
held August 7, 2007 in Boston, MA, in conjunction with the USENIX
Your position paper below has been selected for presentation at the
Workshop and inclusion in the workshop proceedings.
"Delegating Responsibility in Digital Systems: Horton's Who Done It?"
The program committee's reviews for your paper are included below;
please take the comments into account as you revise your paper and
prepare your presentation. As with all referee reports, remember that
different reviewers will sometimes express contradictory opinions.
You (or a coauthor) will be expected to make a brief (10-15 minute)
presentation that serves as a starting point for a discussion that you
will then lead. Participants will be asked to be critical,
provocative, and creative in responding to your presentation; we will
expect and encourage lively discussion and debate.
We received 30 position paper submissions and selected only 10 for
presentation. Papers were selected especially for their potential to
stimulate interesting discussion and to inspire new research
The workshop registration site is up with an early registration deadline
of July 27, 2007. Since the workshop is by invitation only, please send
me the name of the registering participants, so I can approve these
registrations (email to hotsec07chair at usenix.org). For more
see the registration web site at:
Congratulations again on your paper, and I look forward to seeing you
HotSec 2007 Chair
Title: Delegating Responsibility in Digital Systems: Horton's Who
Authors: Mark Miller
Email: erights at gmail.com
This paper proposes to solve tracking problems in capability systems.
To be honest, I found this paper a little hard to follow as it seemed
to be a stream of conciousness description of an design with little
supporting text to clairfy the assumptions or tell me what challenges
were faced. Alot of the paper was filler (code, figures without
meaningful captions, ...), so I would expect the authors could have
made the reason to care a little more clear.
- While I thought the abstract was cute, it did not really help me
understand the framing of the paper. Given my trouble really
grasping the details, it would have helped to frame the ideas at the
- In the end, the solution seemed to be thin on idea. Why is this
The authors propose to 'delegate responsibility' when delegating
by attributing actions in object capability systems. The goal is to
access not to the party delegating access but to the party
abusing access. If A delegates access to B and B abuses the delegated
access to C, then C can revoke B without impacting A as long as C can
identify B and
distinguish it from A. The paper is convincing in its argumentation. To
improve the paper, the authors could examine the scalability of their
approach and apply it to a challenging access control problem (e.g.,
Wikipedia). The authors could also compare it to existing reputation-
This paper describes a new technique for capability based access
conventional capability systems, A delegates to B by passing a
object to B directly. Reference monitors are not able to distinguish
requests by A from requests by B, as both use the same capability. The
authors insightfully note that this corresponds to delegating
but not "responsibility."
The authors propose a system, called Horton, that connects authority and
responsibility. In Horton, capabilities are implemented as stubs (e.g.
objects wrapping the interfaces of resources to be controlled). Stubs
not passed directly as part of delegation. Instead, if A wishes
with the ability to use stub S, A asks the source of S to created a
S'. S' is intended for B's use but returned to A (in wrapped form). A
passes S' to B in place of passing A's own stub. Thus a reference
or log can distinguish requests made by A and B.
With some reservation, I support accepting this paper. The technique of
encoding "watermarked" capabilities as methods appears both promising
novel. However, per my comments below, I found the analysis lacking and
some aspects of the design under-motivated.
* You need to more clearly define reactive access control. I
if you intend to to require that reactive access control methods
associate a human-user with requests. Is revocation a necessary
component of reactive a.c.?
* Assume A has stub S. In lieu of passing S to B, A communicates
a third party to get a (gift-wrapped) stub S', which is suitable
for passing to B. It's not clear to me why A and B cannot
S' on their own. Perhaps there is a technical reason why
chaining cannot be "lifted" to implement stubs, but I don't
Requiring A to communicate with the owner of S appears to
the system. Perhaps this is necessary, but the authors provide
no discussion of why that is. This is a major omission.
* Page 3 discusses running Horton across "mutually suspicious
and page 4 describes an implementation of unwrap which appears
to require passing a mutable reference between actors. How
model account for this apparently distributed shared state?
* To what extent is Horton transparent to programmers? You mention
transparency in section 2, but it's not clear what a
system architect must do in order to use Horton. What sorts of
objects can be passed as "whoBlame" or "beMe" arguments to
* Similarly, can existing code be easily modified for use with
* You repeatedly mention using Horton to assign blame, but do not
the mechanics of this process. To you intend for Horton messages
to be logged? Is this logging best performed by stubs, or by
the service providers which stubs wrap?
* As described in the paper, you must trust Carol to trust Carol's
For instance, if Carol (mistakenly or maliciously) provides Bob
with Alice's stub, there is no way to distinguish Alice's and
actions. Have you considered this? I suspect it could be
by requiring that proxies endorse stubs at each use.
* What is your attack model? Section 2 discusses the possibility
attempting to forge stubs for B. Are attackers obliged to obey
E's memory safety properties or can they attempt to modify stubs
with a debugger?
* What are the (formal or informal) properties provided by
could a user describe the access control properties of an
written in Horton?
* The paragraph beginning "Only ACLs current support reactive access
control" does not ring true. Your reference  explains how
revocation can be realized in capability based system. I
is related to the ambiguity in definition of reactive access
* Section 2 needs reorganization. Please explain the Horton
and your Alice/Bob/Carol example in text before getting into the
* Please put spaces between text and citations (e.g. "needs "
Text by me above is hereby placed in the public domain
More information about the cap-talk