[cap-talk] Fwd: HotSec '07

[Mark Miller]

On 7/7/07, Jed Donnelley <capability at webstart.com> wrote:
> >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.
>
> That seems a fair criticism,

I agree.

> though what to do given the space
> constraints coupled with the desire to include the 'implementation'
> for reference?
>
> It seems to me we should either get the length limit relaxed
> (unlikely I guess)

I agree that this would be unlikely.

> or perhaps remove or abbreviate (perhaps
> with web references) the implementation and instead focus as
> the reviewer suggests on "supporting text to clarify the
> assumptions or tell <me> the challenges that were faced".

That seems to me as well to be the way to address the referee's
issues. As a short paper, it probably is more important for it to
explain and motivate well what problem we're solving than it is for it
to explain the solution with the current explicitness.



> I agree with the reviewer that it is important to better
> clarify what challenges were faced.  To me it seems we attacked
> a problem that most in the field believed was contrary to
> any use of capabilities and therefore at least in some sense
> couldn't be solved.  I think that is important to say in
> more detail.

Yes.

> Perhaps we need a plan of action for responding to the
> review?  As the lead author, what do you think Mark?

The only expected response is the final paper.


> [...] Horton is "hot" [...] because: [...]

I like your summary. I'm not sure what changes this suggests be done
to the paper.


> >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).
>
> Huh?  Let me see (from Wikipedia - fun that they should start to
> include such references in reviews of papers.  This could be trend,
> perhaps with papers themselves showing up in the Wikipedia articles?)

I don't think they meant any articles on Wikipedia, but rather the
access control problem that Wikipedia itself faces. Indeed, as you
remember, one of my earlier draft intros for motivating Horton was a
tale of the future wiki spam arms race. FWIW, I'll try to find this
text and post it to cap-talk.


> >The authors could also compare it to existing reputation-
> >based systems.
>
> Hmmm.  That seems like a good suggestion.  I took a quick
> look, but this would seem to require a bit of research.

For me as well. What good work is there on this? I found Raph Levien's
perpetually unfinished thesis, "Attack Resistent Trust Metrics"
http://www.levien.com/thesis/compact.pdf interesting. Such schemes
would be nicely complimentary to Horton. But I despair of attempting
to explain the possible relationship in so little space.


> >Specific comments:
> >   * You need to more clearly define reactive access control.  I
> >can't tell
> >       if you intend to to require that reactive access control methods
> >       associate a human-user with requests.

Given the current popularity of CAPCHAs and such, it probably is worth
pointing out that Horton does not need responsible identities to
correspond to humans.


> >       Requiring A to communicate with the owner of S appears to
> >complicate
> >       the system.  Perhaps this is necessary, but the authors provide
> >       no discussion of why that is.  This is a major omission.
>
> I agree - we should discuss this.  Who is this reviewer anyway?
> Do you know Mark?

The referees all chose to remain anonymous. All I know are the names
listed for the Program Committee at
<http://www.usenix.org/events/hotsec07/cfp/>.


> >   * Page 3 discusses running Horton across "mutually suspicious
> >machines,"
> >       and page 4 describes an implementation of unwrap which appears
> >       to require passing a mutable reference between actors.  How
> >does the
> >       model account for this apparently distributed shared state?
>
> Hmmm.  I'm not sure I fully understand this concern.  Is this getting
> at Alan's concerns about supporting identities (whos) across
> multiple organizations?

I don't think so. Rather, I think this reflects the paper's lack of
clarity about which objects would be on which machines in such a
distributed scenario. Given the space constraints, my inclination is
to avoid any hint of discussion about distributed usage, so as not to
raise questions we have no room to answer.


> >   * Similarly, can existing code be easily modified for use with
> >Horton?
>
> Hmmm.  This is an awfully broad request.  I would say that
> code that manages existing ACL based access control will not
> be particularly easy to modify for use with Horton.

Agreed. In fact, I'm inclined to interpret the question much more
narrowly: as asking about whether existing object-capability code that
was written without knowledge of Horton can be easily modified for use
with Horton. The first part of answering this narrower question is to
clarify our transparency claim: that existing ocap application code
that remains ignortant of Horton concepts can go through Horton
transparently.

Much more difficult is the issue of what hooks Horton can provide, so
that ocap applications can be modified to become Horton aware, and
make use of the extra info Horton provides. I think this remains a
difficult design issue Horton needs to face. I have some thoughts on
this, but they're still in a primitive state. The paper should
probably mention this as an open area for future work.



> >   * You repeatedly mention using Horton to assign blame, but do not
> >discuss
> >       the mechanics of this process.  [D]o you intend for Horton messages
> >       to be logged?
>
> I believe the answer to this is yes.

In general. Since Horton provides each participant enough info for
meaningful logging, each other participant is thereby encouraged to
act under the assumption that they will be held responsible for their
actions.


> >Is this logging best performed by stubs, or by
> >       the service providers which stubs wrap?
>
> That's a good question.  Isn't it clear that only the stubs
> have to the authority to do the appropriate logging?

To you and me. If it were clear to the referees, they wouldn't have
asked. We must assume a reader to whom things are no more clear than
they are to the referees.


> >   * As described in the paper, you must trust Carol to trust Carol's
> >log.
>
> An awkward sentence.  I assume he means we trust Carol to
> manage Carol's log - ?

I took this to mean that the record in Carol's log is only according
to Carol, which is true in Horton. Unless you trust that Carol is
logging honestly, you can't trust what Carol's log says about who
should be held responsible for what. In other words, Horton itself (by
design) does not provide non-repudiatable logs. If Carol says to Dave:
"Look what Alice did", Alice can always respond "Carol is lying". At
that point, to Dave, it's only Carol's word against Alice. We probably
need to say something about this design goal in the paper. Sigh.


> >       For instance, if Carol (mistakenly or maliciously) provides Bob
> >       with Alice's stub, there is no way to distinguish Alice's and
> >Bob's actions.
>
> Hmmm.  I don't believe Carol has access to Alice's stub.  That
> is, Carol never gets access to P2 (from the paper), only
> S2.  Carol could of course make up S2, so this is no loss.
> Of course Carol emphatically doesn't get access to the
> beAlice or beBob.

I think the referee was refering to S2 (indeed a stub in the paper's
terminology), not P2 (a proxy). The question is valid as far as it
goes: Carol could respond to the intro message with a gift-wrapped S2
rather than S3, fooling herself into blaming Alice for actions that
Alice asked her to attribute to Bob. If Horton attempted to provide
non-repudiatable logs, this would be a real concern.



> >Have you considered this?  I suspect it could be ameliorated
> >by requiring that proxies endorse stubs at each use.
>
> I guess I'm not clear what he's getting at here.

I don't know what "endorse" means here.


> >Section 2 discusses the possibility
> >of A
> >       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?
>
> I think perhaps MarkM is in the best position to answer this one.
> My concern is mostly with the distributed version of Horton.

In the local case, Horton relies on attackers being unable to violate
E's memory safety properties.

In the distributed case, each participant is assumed able to mess
arbitrarily with the workings of the objects running on their
hardware, but can interact with the other's machines only through the
distributed capability protocol. Alice relies on her protocol handler
to not violate her own memory safety, and therefore to not enable Bob
to remotely cause her memory safety to be violated.


> >   * What are the (formal or informal) properties provided by
> >Horton?  How
> >       could a user describe the access control properties of an
> >application
> >       written in Horton?
>
> I'm not sure what he's getting at here.  An application written
> "in" Horton?  Does he mean an application written 'for' Horton?

I think "for".

> >   * Section 2 needs reorganization.  Please explain the Horton
> >system and
> >       and your Alice/Bob/Carol example in text before getting into the
> >       details.
>
> This seems reasonable to me, but it of course come with the question
> of either:
>
> 1.  Do we get more space, or
> 2.  What do we leave out?

I assume not #1, so #2 is pressing.


> I wonder if we should ask the reviewer what he feels could/should
> be left out so that we can include more explanatory information?

I received no indication that further dialog was expected or welcome.
I think we should respond simply by trying our best to improve the
paper.


> All in all a pretty positive review from my perspective.

I agree. The cluefulness of the referees regarding capabilities I find
most encouraging, and quite an improvement over the recent past. I
take this as a sign of success for all of our activities explaining
and promoting the paradigm!

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM