[cap-talk] Any hope in RSA 2008?

Jed Donnelley capability at webstart.com
Fri Apr 4 13:35:01 EDT 2008


At 06:49 AM 4/4/2008, Mark Miller wrote:
>On Fri, Apr 4, 2008 at 3:28 AM, Jed Donnelley <capability at webstart.com> wrote:
> >  >These folk are trying to "solve" the problem in the sense of
> >  >"what can I do in the next three weeks", not "how can I rebuild the
> >  >world to be a better place".
> >
> >  Right.  However, I would think that by now since we've been
> >  doing what we can for the next three weeks for the last 15 years
> >  at least and it things haven't gotten better (they've gotten
> >  worse) then it does seem pretty clear to me that this three
> >  week horizon process is not making positive progress.
>
>Borrowing an analogy from Engines of Creation:
>
>We're on a sinking ship that has been kept afloat by a vigorous
>bailing process. Early on, some people expressed an interest in
>actually fixing the holes. But these efforts were not immediately
>successful, and most of those folks went on to other things. Now, the
>holes have gotten bigger, the bailing is less effective, and the ship
>is carrying a lot more valuable cargo. But there are a lot more people
>bailing, they are well paid, and hardly anyone believes any
>alternative is possible. After all, bailing is what's worked so far.

Good analogy.  It fits well with the analogy I used in the
draft prospectus for the Capability Systems Workshop where I said:
________
One straight forward approach to solving the computer security 
problem hasn't been tried in the modern era.  This approach is that 
of Principle Of Least Authority (POLA) computing.  Just as ship 
builders learned that by having multiple water tight compartments in 
their ships they could keep them from sinking if a compartment was 
breached, computer systems can be made resilient to breaches (e.g. 
viruses or other forms of "malware") if they are composed of multiple 
"water tight" (mutually suspicious) compartments.
________

Perhaps I can use something along these lines when it comes to a
call for papers - if we get there (more below).

Regarding:

At 03:41 AM 4/4/2008, Jonathan S. Shapiro wrote:
>On Fri, 2008-04-04 at 03:28 -0700, Jed Donnelley wrote:
> > At 02:41 AM 4/4/2008, Jonathan S. Shapiro wrote:
> > >These folk are trying to "solve" the problem in the sense of
> > >"what can I do in the next three weeks", not "how can I rebuild the
> > >world to be a better place".
> >
> > Right.  However, I would think that by now since we've been
> > doing what we can for the next three weeks for the last 15 years
> > at least and it things haven't gotten better (they've gotten
> > worse) then it does seem pretty clear to me that this three
> > week horizon process is not making positive progress.
>
>I agree, but that's not the group that this conference is marketing to.

Ah, so where is the conference that is marketing to the long
term solution group?  Where is that group?  Those are the
people I want to talk to.

> > >In that light, methods for ensuring that processes are followed, and for
> > >knowing which systems need to be reviewed when a compromise in subsystem
> > >X is discovered, are very useful things.
> >
> > Yes.  They are useful things, but clearly (by now) not solving
> > the problem.
>
>Depends what "the problem" is.

"the problem" is poor computer security/integrity that takes
heroic effort just to keep it afloat (bailing and patching).

> > So I still ask, is there any hope visible in RSA 2008?
>
>This is a marketing conference. Why would you look to this gathering for
>hope?

Because conferences like RSA 2008 and the Usenix Security conference
are the most visible that I see.  Please, point me to the conferences
(workshops, whatever) that are focusing on solving the long term
problem.

> > That is, not just
> > imagined improvement over three weeks assuming that nothing
> > else changes - which of course it does.
>
>I don't think that the customers delude themselves into believing that
>improvement has occurred. What has occurred is survival.

Certainly the marketing suggests in many instances that each
new bailing technique will be the one that finally solves "the
problem" once and for all.  If the customers aren't taken in
by this then perhaps they might be ready customers for anything
that promises a more permanent solution.  Unfortunately we
seem a long way from bringing anything more like a solution
to market, which brings me to:

At 07:39 AM 4/4/2008, David Wagner wrote:
>Folks on the Linux kernel mailing list seem to have a saying for
>when someone says "Wouldn't it be nice if the kernel had feature X?"
>(when that someone seems to be implicitly expecting someone else to
>implement feature X for them).  The response is: "Send code."  The
>implication being that, of course, code is often a lot more useful
>than gripes.  And for those who aren't willing or able to write code
>or to provide resources (money) to enable others to write code, well,
>maybe they shouldn't complain too much.

I believe there has been plenty of code written.  I don't believe
a lack of code is the problem in this space.  Perhaps a lack of
code in some specific areas, but even there I don't see a lack
of code generally (e.g. where are the Horton reference implementations
being applied), but perhaps you can argue that there is a lack of
the "right" code?  What code would that be?

Regarding:

>That brings me to the complaints about the current state of research on
>computer security.  To that, I can only say: "Send research."  I'm of
>the opinion that leading by doing (by forging ahead and setting the kind
>of example you'd like to see others follow) tends to be more effective
>than complaining that everyone else's work in this area sucks.  Before
>criticizing researchers too harshly, spend some time in their shoes.

and:

At 09:02 AM 4/4/2008, Jonathan S. Shapiro wrote:
> >That brings me to the complaints about the current state
> > of research on computer security.  To that, I can only
> > say: "Send research."
>
>Please don't. With apologies to David, whose work is generally 
>excellent, we already have more bad research than we can handle. 
>Fund follow-through, and stop accepting research results that cannot 
>be transitioned.

I'm sympathetic to both positions.  I'm doing what I can to "send
research".  Perhaps you (DavidW) could be a bit more specific by
what you mean.  I agree with Jonathan that most of the research I
see in this area still fits into what I regard as the bailing and
patching category vs. a category working on water tight compartments.

I want to cut back on support for the bailing and patching category
of research, which I feel that are is adequately covered
by industry, and find a way to support more work on water tight
compartments.  I see everything I've done on this list from analyzing
P-1935 to work on Horton to work on the Capability Systems Workshop
in this light.  I'm open to suggestions on ways to be more effective
in this regard.  I consider this thread as a request for people
(beyond cap-talk which of course I'm familiar with) who can be
considered an audience for such long term solution work or mechanisms
to support such work.

I notice you (DavidW) haven't participated in the cap-conf list.
I'm struggling a bit to get sponsorship (no significant dollars as
it's low cost and zero budgeted, mostly institutional credibility
is needed at this point) for the Capability Systems Workshop that
I've proposed.  Maybe I'm going about this the wrong way or that
workshop is the wrong approach?  If so, please make positive
suggestions.  Perhaps you can suggest somebody else with some
visibility (e.g. into the institutions like the IEEE and the
ACM) that can help?  I'd be delighted to have somebody take over,
if not this workshop then some other workshop that might be more
effective in moving us to a solution for the long term problem.
I'm happy to help in any way I can with grunt work.  To me the
problem at this time seems a lack of leadership toward a long
term solution.

Suggestions?

--Jed  http://www.webstart.com/jed-signature.html 



More information about the cap-talk mailing list