[tahoe-lafs-trac-stream] [tahoe-lafs] #1426: re-key (write-enabler) protocol

[tahoe-lafs]

#1426: re-key (write-enabler) protocol
------------------------------+-----------------------
     Reporter:  warner        |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  undecided
    Component:  code-mutable  |    Version:  1.8.2
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by zooko):

 Replying to [comment:3 davidsarah]:
 >
 > The impact of that is an extra signature and round-trip (for each server
 whose write-enabler has been attacked, in parallel) when an honest client
 later tries to modify the file. Is it worth the attacker's cost (a round-
 trip to set the enabler) to perform that attack?

 I find it difficult to evaluate cost/benefit for denial-of-service attacks
 and defenses. I guess the question is how much is it worth to the attacker
 to deny the user the ability to update this file. Obviously we have no
 idea--that depends on the attacker, the user, and what's in that file!

 A better question--a tighter bound--is whether this defense would increase
 the cost of this attack so that it is not the cheapest way to deny
 service. For example, the attacker could accomplish the same goal by
 preventing all of the user's packets from reaching the servers, or by
 compromising the servers. Would this attack be cheaper than that?

 In at least some cases, injecting false packets is a lot cheaper (more
 doable) than censoring out all real packets or compromising all servers.
 In that case, this attack would be the cheapest way to accomplish the goal
 and for that case this defense would help.

 > Yes, I now think we should do this.

 Cool. :-)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1426#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage