wiki:Summit2Day1

Version 1 (modified by warner, at 2011-11-09T09:19:21Z) (diff)

add report from day 1

Day 1

Tuesday 08-Nov-2011. Mozilla SF.

Attendees (with IRC nicks)

  • Brian Warner (warner)
  • Zooko (zooko)
  • David-Sarah Hopwood (davidsarah)
  • Zancas (zancas)
  • Shawn Willden (divegeek)
  • Zack Weinberg (zwol?)
  • Zack Kansler (zwol?)
  • Online: amiller, Dcoder

Agent/Gateway split

  • Shawn Willden observed that "tahoe backup" is usually run on a laptop (frequently sleeping/offline), whereas he's got some other machine (a desktop or home server) with limited CPU which *is* online 24/7, so he wants a backup program that quickly dumps the laptop's contents to the server, then (slowly/lazily) uploads that data from the server into Tahoe
    • extra points for only putting ciphertext on that server
  • Brian wants a long-running process (specifically a twisted.application.service.Service object) to manage backup jobs, storing state in a sqlite db (which directories have been visited, time since last backup, ETA). Likewise for renew/repair/rebalance jobs.
    • maybe web interface to control/monitor these jobs
  • vague consensus was to introduce an "Agent" service, distinct from the current "Client/Gateway?" service. The normal client/gateway process will include both (and the co-resident Agent will have local access to the IClient object for upload/download). But it will also be possible to create one in a separate process (with no client/gateway), in which case it speaks WAPI over HTTP (and must be configured with a node.url).
  • backup and renew/repair/rebalance jobs run in an Agent
  • not sure about where the WAPI/WUI lives. One idea was to have the Agent provide the WUI, and the C/G provide the WAPI. Another is to have the C/G provide most webapi but add new webapi to the Agent for managing backup/renew/repair/rebalance jobs

server-selection UI

expected vs required vs known, k-of-N, H, points, understandability

  • Brian talked about an old #467 explicit-server-selection message and his proposed UI to list all known servers in a table, with "use this server?" and "require this server?" buttons
  • David-Sarah (and Zooko) pointed out that "require?" is a bit harsh given our current H= ("Servers Of Happiness") share-placement code
  • tradeoffs between clear-and-restrictive vs confusing-but-fails-less
  • challenge of identifying reliability of nodes
  • Brian says client/gateway should expect user to teach it what sort of grid they expect, so it can bail when expectations aren't met
  • Shawn would prefer scheme where client measures reliability itself, chooses k/N/H to meet certain speed/cost/reliability goals

encrypted git, or revision control on tahoe

  • Zack(?) is thinking about revision control on top of Tahoe, will present "big crazy idea" later when everyone is there
  • Brian mentioned his signed-git-revisionid project (not yet released), and how git fetch/push is fast because both sides know full revision graph and can compute missing objects in one RTT. To get this in Tahoe, we must add deep-(verify)-caps and let servers see shape of directory tree.
  • Lunch conversation about Monotone's mutable metadata and the problem of transferring it efficiently

grid management

non-transitive one-at-a-time invitations, transitive clique invitations, Grid Admin star config

  • Brian is thinking about grid setup and Accounting, and pondering a startup mode where servers issue Invitations to clients
    • pasting Invitation code into a web form is sufficient to get connected to grid (combines Introducer functionality with Account authorization)
    • probably set up bidirectional connection: when Alice accepts Invitation from Bob, both Alice and Bob can use each other's storage
  • three modes:
    • issue/accept one Invitation per link
    • each node needs one Invitation to join clique, then they get access to all storage servers in the clique (and offer service to all clients in the clique): grid grows one node at a time
      • issue: can two grids merge? or can you only accept an invitation when you aren't already in a grid?
    • managed grid: a central Grid Admin is the only one who can issue Invitations. When accepted, Alice can use storage of all members.
  • Shawn thinks a Request model is more natural: Server admin (or Grid Admin) sends ambient URL to new user, they paste it into a field that says "Request Access", this sends a Request to the server (probably containing a pubkey), the server records it, then later the server admin Accepts or Rejects the request.
  • Invite and Request are duals, modulo some channel and workflow variations (confidential vs authentic, who-sends-first-message)
  • Brian will explore how hard/feasible it is to run one workflow on top of the other: can a Request be expressed with a note saying "please send an Invitation to this public encryption key" sent to the server?

#466 new-introducer review

  • Brian walked through most of the #466 new-introducer code (https://github.com/warner/tahoe-lafs/tree/466-take7) with David-Sarah and Zooko
  • David-Sarah found one critical security bug (signature checking failure), lots of good cleanups to recommend, tests to add
  • overall it looks good
  • Brian will make suggested cleanups and prepare for landing

Beer!

signature consensus!

  • over drinks, Brian and David-Sarah and Zooko discussed signature options (needed for #466, Accounting, non-Foolscap storage protocol, new mutable file formats)
  • choices:
    • python-ed25519 (standalone C extension module)
    • python-ecdsa (standalone pure-Python module)
    • ECDSA from Crypto++ via pycryptopp
    • non-EC DSA (eww)
    • get Ed25519 into Crypto++, then expose in pycryptopp
    • add Ed25519 into pycryptopp (making it more than just a python binding to Crypto++, hence nicknamed "pycryptoppp")
    • get ECDSA from pyOpenSSL (we think it isn't exposed)
  • evaluation:
    • security: David-Sarah strongly prefers Ed25519, Zooko slightly prefers ECDSA (older, more exposure), Brian (who currently has a crush on everything 25519) slightly prefers Ed25519. Crypto++'s entropy-using signature code includes nonce-safety (entropy is hashed with message to mitigate VM-rollback failure). Ed25519 has deterministic signatures and nonce-safety.
    • speed: requirement is <10s startup with 100 servers (specifically, make sure the Announcement sign/verify is small compared to connection establishment time). That's sign+verify<100ms . This rules out python-ecdsa (sign+verify=330ms). Both a non-pure-python ECDSA and Ed25519 will do. A really fast primitive (optimized Ed25519 is like 20us) might enable new applications in the future (key-per-lease, key-per-write-request).
    • pure-python: slight preference for something that could be pure-python in the future if PyPy could make it fast enough. Seems unlikely in the near-term for any of the options.
    • patents: murky, of course. Redhat/Fedora core currently eschew all ECC, might change, might not, too bad. Not a clear differentiator between ECDSA and Ed25519. Nobody was willing to tolerate non-EC DSA (would need 4kbit keys to feel safe, not confident of hitting speed requirements). We can always back it out if it proves to be a problem (at the cost of regenerating all serverids). Hopefully the scene will settle down before we want to use it for data (which would be harder to back out).
    • packaging: biggest differentiator
      • python-ed25519: must build eggs as we did for pycrypto, need to get into debian (which has other benefits, but delays tahoe), increases build pain marginally.
      • python-ecdsa (too slow, ruled out): pure-python, so no need for eggs, but still need to get into debian and increases build pain
      • ECDSA-via-pycryptopp: easy, code is mostly done, needs final review and polish, no new dependencies.
      • ed25519-in-Crypto++: probably good idea in long term, but will take a while (must convince Crypto++ to change, wait for a release, then add bindings to pycryptopp). Must also wait for distributions to pick up new Crypto++. Technically no new dependencies, but increases the version requirements on an external module with a historically slow (1/yr) release cycle.
      • ed25519-in-pycryptopp: a bit weird (pycryptoppp), fairly fast (we control pycryptopp), no external delays. No new dependencies.
  • winner: ed25519-in-pycryptopp (aka pycryptoppp). Ed25519 wins over ECDSA with potential better security and future-coolness-enabling speed. Delivering in pycryptopp means no new dependency and no external parties to block.
  • future goal is to get python-ed25519 into debian, then switch Tahoe to depend on it instead. And/or once Ed25519 gets into Crypto++, remove the separate implementation from pycryptopp (i.e. remove one "p" from pycryptoppp) and have pycryptopp rely on Crypto++'s version.
  • also, get pycryptopp's ECDSA finished off in the ed25519-bearing release, just to have it available.

Attachments (3)