"Chilling Effects" paper at USENIX

Wed Apr 9 14:04:26 EDT 2008

The paper is over-alarmist due to 2 fundamental errors:

1. Assumes the spec has been implemented (forgivable, could be fixed by a
global tense change to the conditional).

2. Paper reads: "The P IDENT policy states that "all digital *peer*interactions
or communication (e-mails, instant messages, and so forth)
can be cryptographically signed to maintain integrity even
as they're routed through potentially malicious peers on the
mesh." Since the policy does not state the conditions under
which traffic will or will not be signed, and the "unobtrusive
security" goal emphasizes that "strong unobtrusive security"
will occur "behind the scenes" unless it impacts usability—
not privacy—we must assume that *all outgoing traffic* will be
signed by default when possible." (emphasis mine, for contrast). HTTP
requests are not *peer* interactions, and this is makes all that follows
invalid.

Nevertheless, the paper does point to 2 serious flaws in the spec.

1. Key escrow - This is fundamental, and I have proposed a mechanism for
automatic peer-escrow (using key shares) that would accomplish the backup
goal yet be significantly resistant to the flaws the paper points to. It
will probably be about a year before this would be implemented, at current
rates of development; nevertheless, if they're going to judge us on our
goals and not our accomplishments anyway, it may behoove us to update the
spec with some scheme like this.

2. Unauthorized backup servers - the simplest, most obvious response to this
issue is to specify that all private data is encrypted before being backed
up. (This is actually left as an open question in the spec, so it is
possible to argue that the criticism in the paper should have been
qualified.)

I think, therefore, that the best response is summed up in the paper itself:
"As there has been much work on privacy-preserving systems
in recent years, it is our intuition that most, if not all,
of the problematic aspects of Bitfrost can be eliminated by
refining the specification". In other words, let's ignore some of the
chicken-little language of the paper, but take its valid criticisms to
heart.

Jameson

On Wed, Apr 9, 2008 at 10:58 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 09.04.2008 05:50, Jaya Kumar wrote:
> > On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin <jpritikin at pobox.com>
> wrote:
> >
> >> On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote:
> >>  > A paper called "Freezing More Than Bits: Chilling Effects of the
> OLPC XO
> >>  > Security Model" will be presented next Monday at USENIX UPSEC'08
> [1].  The
> >>  > author has kindly posted the paper at [2], which I discovered after
> Google
> >>  > took me to her weblog [3].
> >>
> >>  This paper is depressing. Why didn't the authors step up and
> >>  contribute instead of criticizing from the citadel?
> >>
> >>  This paper is dead on arrival.
> >>
>
> No, the paper is dead-on.
>
> > I think your reaction is dismissive rather than addressing the
> > author's criticism.
> >
> > Forgive me if I'm wrong, I'm no expert, but it looks to me like the
> > paper makes specific technical criticisms and seems quite detailed. I
> > think it would be more positive and productive to respond to the
> > technical statements made in the paper rather than to be dismissive
> > and ignore what looks to some of us like valuable feedback.
> >
>
> Some of the criticisms in the paper have been mentioned on the security@
> list over a year ago. The reactions were twofold: Some were ridiculed,
> others were ignored.
> It seems this academic paper was the only way to get meaningful
> responses. Then again, most of the comments about the paper were either
> flames or otherwise dismissive instead of disproving any of the claims
> made in the paper.
>
> Anybody who has not completely read both the bitfrost spec and the
> USENIX paper should shut up now. I have read the Bitfrost spec and was
> one of the first persons to comment on it directly after it was
> published. That's why I dismiss most of the comments on this list about
> the USENIX paper - it is too obvious that commenters did not read and
> understand the Bitfrost spec.
>
> Oh, and by the way, http://wiki.laptop.org/go/OLPC_Bitfrost states "We
> welcome feedback on this document, preferably to the public OLPC
> security mailing list
> <http://mailman.laptop.org/mailman/listinfo/security>". There is NO
> point in contacting any Bitfrost author privately to point out flaws -
> it would go squarely against published official OLPC policy.
>
> Regards,
> Carl-Daniel
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080409/10f47853/attachment.html>