[tahoe-lafs-trac-stream] [tahoe-lafs] #510: use plain HTTP for storage server protocol

[tahoe-lafs]

#510: use plain HTTP for storage server protocol
------------------------------+---------------------------------
     Reporter:  warner        |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.2.0
   Resolution:                |   Keywords:  standards gsoc http
Launchpad Bug:                |
------------------------------+---------------------------------

Comment (by warner):

 Some notes from the 2011 Tahoe Summit:

 We can't keep using shared-secret prove-by-present-it write-enablers
 over a non-confidential HTTP transport. One approach would be to use a
 verifying key as the write-enabler, and sign the serialized mutation
 request message, but that would impose a heavy CPU cost on each write (a
 whole pubkey verification).

 A cheaper approach would use a shared-secret write-enabler to MAC the
 mutation request. To get this shared secret to the server over a
 non-confidential channel, we need a public-key encryption scheme. The
 scheme David-Sarah and I cooked up uses one pubkey-decryption operation
 per server connection, and avoids all but one verification operation per
 re-key operation. Normal share mutation uses only (cheap) symmetric
 operations.

 Basically, each client/server pair establishes a symmetric session key
 as soon as the connection is established. This involves putting a public
 encryption key in the #466 signed-introducer announcement, maybe as
 simple as a DH g^x^ parameter (probably an elliptic-curve group
 element). At startup, the client picks a secret, creates g^y^, sends it
 in a special message to the server, and the resulting shared g^xy^ is
 the session key. The client could use a derivative of their persistent
 master secret for this, or it could be random each time, doesn't matter.

 The session key is used in an authenticated-encryption mode like CCM or
 basic AES+HMAC. When a #1426 re-key operation is performed, the signed
 please-update-the-write-enabler message is encrypted with the session
 key, protecting the WE from eavesdroppers. The server checks the re-key
 request's signature and stores the new WE next to the share.

 To actually authorize mutate-share operations, the request is
 serialized, then MACed using the WE as the secret key. Requests without
 a valid MAC are rejected. This uses only cheap hash operations for the
 mutation requests. The expensive pubkey ops are only used once per file
 per serverid-change (migration) during re-keying, and one per connection
 to establish the session key.

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