[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:  taral
         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 zooko):

 Taral:

 The protocol messages are the methods of the classes which subclass
 {{{RemoteInterface}}} and are listed in
 [source:trunk/src/allmydata/interfaces.py?rev=5212 interfaces.py]. For
 example, to upload an immutable file, you get a remote reference to an
 [source:trunk/src/allmydata/interfaces.py?rev=5212#L41 RIBucketWriter] and
 call its methods {{{write()}}} and {{{close()}}}.

 About crypto:

 Note that we're talking only about the encryption used to protect
 authorization of users to do certain things. There is another use of
 encryption, which is to protect the confidentiality of the file data, and
 that we already do in our own custom way (since TLS doesn't really apply
 to files the way Tahoe-LAFS users use them).

 The current version of Tahoe-LAFS protocol does actually run over SSL/TLS
 and rely on that to protect certain authorization secrets. The most
 important authorization secret is called the "write enabler", which you
 can read more about in [source:docs/specifications/mutable.rst
 specifications/mutable.rst],
 [source:trunk/src/allmydata/interfaces.py?annotate=blame&rev=5212#L178
 interfaces.py], client-side
 [source:trunk/src/allmydata/mutable/publish.py?annotate=blame&rev=5231
 mutable/publish.py] and
 [source:trunk/src/allmydata/mutable/filenode.py?annotate=blame&rev=5227
 mutable/filenode.py], and server-side
 [source:trunk/src/allmydata/storage/mutable.py?annotate=blame&rev=5239
 storage/mutable.py].

 When developing a new HTTP(S)-based protocol, we have to decide whether to
 implement our own encryption to manage authorization or to continue using
 the "enablers" design on top of SSL/TLS (thus making it be an HTTPS
 -only protocol and not an HTTP-protocol). I think it may actually ease
 deployment and usage to do the former, because SSL/TLS is a bit of a pain
 to deploy. I think it may actually also simplify the protocol! This is
 somewhat surprising, but what we need is an authorization protocol and
 what SSL/TLS provides is a two-party confidential, integrity-preserving
 channel with server-authentication. It kind of looks like implementing our
 own crypto authorization protocol may be simpler (such as described in
 comment:11) may result in a simpler protocol than implementing an
 authorization protocol layered on top of a secure channel protocol.

 Our custom protocol would also be a bit more efficient, where efficiency
 is measured primarily by number of required round-trips.

 (Note that Brian Warner's {{{foolscap}}} is already a general-purpose
 authorization protocol built on top of SSL, but it doesn't quite fit into
 our needs because of a few efficiency considerations including the size of
 the foolscap authorization tokens (furls). Also, foolscap includes a
 Python-oriented remote object protocol and the whole point of this ticket
 is to get away from that. :-))

 I don't have time to dredge up all the pros and cons that we've talked
 about, but if anyone does remember them or find them, please post them to
 this ticket or link to them from this ticket.

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