devchat notes 16-May-2017

[Brian Warner]

Tahoe-LAFS devchat 16-May-2017

Attendees: warner, exarkun, simpson, meejah, cypher

* simpson: phone app ideas
 * capn-based frontend, leave foolscap out of the phone side
* trying to prototype grid manager at pycon
* simpson is concerned about having account identifiers on data
 * maybe we could use the same account for everybody?
* what if grid-manager could announce that servers will accept anonymous
  clients?
 * known servers, but anonymous clients
 * clients either use no key (account="anonymous"), or the grid manager
   gives everyone the same private key
 * servers are told whether to accept anonymous or not
* maybe if the client uses --tor, then they must also make an explicit
  choice about pubkey=anonymous vs pubkey=pseudonym
* how should the accounting reports be delivered?
 * warner really wants to call these TPS reports, can't justify why
* don't assume we can do anything exotic with TLS: no client certs, no
  changes to the validation function
 * HTTP, sign the request, include a curve25519 pubkey in the request,
   then response is encrypted to that pubkey
 * TLS: requires access to port 443, deployment hassle
* so: define signed-encrypted-HTTP protocol
 * storage server publishes both URL and a curve25519 encryption pubkey
   in Introducer announcement
 * grid-manager signs the "give me your accounting report" reuest,
   encrypts to the pubkey, POSTs to URL
  * request include an ephemeral curve25519 pubkey for the response
 * server builds response, encrypts to the pubkey, returns in body
 * need to check: is keeping this pubkey secret ok? could an attacker
   submit an alternate report
 * request includes a nonce/request-id in the encrypted part of the
   request
 * reponse should include the same nonce in the encrypted body
 * grid-manager checks the nonce
 * use the nonce for replay protection too
* task list:
 * define signed-encrypted-HTTP protocol for TPS report delivery
 * build the grid-manager node: CLI commands, "tahoe grid-manager
   create"
 * maybe prototype new WAPI here: websockets, single-page-app WUI
  * assign petnames, view storage reports
 * client-side changes:
  * "create-client --managed" switch to use managed mode?
  * "create-client --manager-invitation=CODE" ? should only happen once
  * "create-client --managed": then immediately asks for a code, doesn't
    accept any other arguments
  * avoid including a "tahoe accept" command: don't suggest it could be
    run multiple times
  * "create-managed-client"
   * asks for code
   * spawns "create-client" with args
  * manual (non-invitation) managed setup: "tahoe create-client
    --manager-pubkey=XYZ --introducer=FURL"
  * reacting to the manager announcement:
   * updating the default encoding parameters
   * remembering the authorized server list
  * StorageFarmBroker: if a manager key is set, then only use servers
    from the signed list
   * subscribe to manager announcements
   * check signature on the published server list
   * change get_servers_for_peer_selection_index to test against the
     list before adding to permuted ring
   * don't initiate connections to servers that aren't on the list
   * shut down Reconnectors for servers that are no longer on the list
   * basically compute intersection of authorized-servers (from manager)
     and known-servers, make sure there's a Reconnector for each member
     of the intersection, shut down any other Reconnectors
   * uploads in progress when a server is revoked should continue to use
     the old server
   * but uploads that start after revocation should not
  * accounting changes: furlification, client-side accounting keys
    (ed25519), .tahoe/private/account.key
 * server-side
  * Account desk (furlification, clients connect, exchange signed
    request for account-specific storage server object)
  * desk needs to compare requests against the manager's authorized
    accounts list
  * maybe create the account-specific object for anyone who shows up,
    but each request tests for membership in the authorized-client list
   * which would help with ordering
    * an upload that happens during the invitation race window might be
      rejected, but later ones will succeed
 * think about ordering: could a client show up at the server before the
   server hears the client list?
  * may need to buffer some requests until their authorization shows up
    later?
  * or sequence actions to avoid this
  * add IntroducerClient API? make subscribe() idempotent, re-fire
    callbacks with all records each time subscribe() is called
   * goal is to avoid needing to remember previously-ignored
     announcements, somehow??
  * maybe manager should wait until it sees the new-client announcement
    propagate through the Introducer before letting the client proceed
   * maybe add a few more seconds too
  * or clients can just retry if they get rejected
   * this will be a rejection during furlification, so Reconnector won't
     help, unless the client drops the connection entirely
   * clients could retry furlification later