The paper is over-alarmist due to 2 fundamental errors:<br><br>1. Assumes the spec has been implemented (forgivable, could be fixed by a global tense change to the conditional).<br><br>2. Paper reads: "The P IDENT policy states that "all digital <b><i>peer</i></b> interactions<br>
or communication (e-mails, instant messages, and so forth)<br>can be cryptographically signed to maintain integrity even<br>as they're routed through potentially malicious peers on the<br>mesh." Since the policy does not state the conditions under<br>
which traffic will or will not be signed, and the "unobtrusive<br>security" goal emphasizes that "strong unobtrusive security"<br>will occur "behind the scenes" unless it impacts usability—<br>not privacy—we must assume that <b><i>all outgoing traffic</i></b> will be<br>
signed by default when possible." (emphasis mine, for contrast). HTTP requests are not <u>peer</u> interactions, and this is makes all that follows invalid.<br><br>Nevertheless, the paper does point to 2 serious flaws in the spec.<br>
<br>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.<br>
<br>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.)<br>
<br>I think, therefore, that the best response is summed up in the paper itself: "As there has been much work on privacy-preserving systems<br>in recent years, it is our intuition that most, if not all,<br>of the problematic aspects of Bitfrost can be eliminated by<br>
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.<br><br>Jameson<br><br><div class="gmail_quote">On Wed, Apr 9, 2008 at 10:58 AM, Carl-Daniel Hailfinger <<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On 09.04.2008 05:50, Jaya Kumar wrote:<br>
> On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin <<a href="mailto:jpritikin@pobox.com">jpritikin@pobox.com</a>> wrote:<br>
><br>
>> On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote:<br>
>>  > A paper called "Freezing More Than Bits: Chilling Effects of the OLPC XO<br>
>>  > Security Model" will be presented next Monday at USENIX UPSEC'08 [1].  The<br>
>>  > author has kindly posted the paper at [2], which I discovered after Google<br>
>>  > took me to her weblog [3].<br>
>><br>
>>  This paper is depressing. Why didn't the authors step up and<br>
>>  contribute instead of criticizing from the citadel?<br>
>><br>
>>  This paper is dead on arrival.<br>
>><br>
<br>
</div>No, the paper is dead-on.<br>
<div class="Ih2E3d"><br>
> I think your reaction is dismissive rather than addressing the<br>
> author's criticism.<br>
><br>
> Forgive me if I'm wrong, I'm no expert, but it looks to me like the<br>
> paper makes specific technical criticisms and seems quite detailed. I<br>
> think it would be more positive and productive to respond to the<br>
> technical statements made in the paper rather than to be dismissive<br>
> and ignore what looks to some of us like valuable feedback.<br>
><br>
<br>
</div>Some of the criticisms in the paper have been mentioned on the security@<br>
list over a year ago. The reactions were twofold: Some were ridiculed,<br>
others were ignored.<br>
It seems this academic paper was the only way to get meaningful<br>
responses. Then again, most of the comments about the paper were either<br>
flames or otherwise dismissive instead of disproving any of the claims<br>
made in the paper.<br>
<br>
Anybody who has not completely read both the bitfrost spec and the<br>
USENIX paper should shut up now. I have read the Bitfrost spec and was<br>
one of the first persons to comment on it directly after it was<br>
published. That's why I dismiss most of the comments on this list about<br>
the USENIX paper - it is too obvious that commenters did not read and<br>
understand the Bitfrost spec.<br>
<br>
Oh, and by the way, <a href="http://wiki.laptop.org/go/OLPC_Bitfrost" target="_blank">http://wiki.laptop.org/go/OLPC_Bitfrost</a> states "We<br>
welcome feedback on this document, preferably to the public OLPC<br>
security mailing list<br>
<<a href="http://mailman.laptop.org/mailman/listinfo/security" target="_blank">http://mailman.laptop.org/mailman/listinfo/security</a>>". There is NO<br>
point in contacting any Bitfrost author privately to point out flaws -<br>
it would go squarely against published official OLPC policy.<br>
<br>
Regards,<br>
<font color="#888888">Carl-Daniel<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br>