| | 1 | = Day 1 = |
| | 2 | Tuesday 08-Nov-2011. Mozilla SF. |
| | 3 | |
| | 4 | == Attendees (with IRC nicks) == |
| | 5 | * Brian Warner (warner) |
| | 6 | * Zooko (zooko) |
| | 7 | * David-Sarah Hopwood (davidsarah) |
| | 8 | * Zancas (zancas) |
| | 9 | * Shawn Willden (divegeek) |
| | 10 | * Zack Weinberg (zwol?) |
| | 11 | * Zack Kansler (zwol?) |
| | 12 | * Online: amiller, Dcoder |
| | 13 | |
| | 14 | == !Agent/Gateway split == |
| | 15 | - Shawn Willden observed that "tahoe backup" is usually run on a laptop |
| | 16 | (frequently sleeping/offline), whereas he's got some other machine (a |
| | 17 | desktop or home server) with limited CPU which *is* online 24/7, so |
| | 18 | he wants a backup program that quickly dumps the laptop's contents to |
| | 19 | the server, then (slowly/lazily) uploads that data from the server |
| | 20 | into Tahoe |
| | 21 | - extra points for only putting ciphertext on that server |
| | 22 | - Brian wants a long-running process (specifically a |
| | 23 | twisted.application.service.Service object) to manage backup jobs, |
| | 24 | storing state in a sqlite db (which directories have been visited, |
| | 25 | time since last backup, ETA). Likewise for renew/repair/rebalance |
| | 26 | jobs. |
| | 27 | - maybe web interface to control/monitor these jobs |
| | 28 | - vague consensus was to introduce an "Agent" service, distinct from |
| | 29 | the current "Client/Gateway" service. The normal client/gateway |
| | 30 | process will include both (and the co-resident Agent will have local |
| | 31 | access to the IClient object for upload/download). But it will also |
| | 32 | be possible to create one in a separate process (with no |
| | 33 | client/gateway), in which case it speaks WAPI over HTTP (and must be |
| | 34 | configured with a node.url). |
| | 35 | - backup and renew/repair/rebalance jobs run in an Agent |
| | 36 | - not sure about where the WAPI/WUI lives. One idea was to have the |
| | 37 | Agent provide the WUI, and the C/G provide the WAPI. Another is to |
| | 38 | have the C/G provide most webapi but add new webapi to the Agent for |
| | 39 | managing backup/renew/repair/rebalance jobs |
| | 40 | |
| | 41 | == server-selection UI == |
| | 42 | |
| | 43 | expected vs required vs known, k-of-N, H, points, understandability |
| | 44 | |
| | 45 | - Brian talked about an old #467 explicit-server-selection message and |
| | 46 | his proposed UI to list all known servers in a table, with "use this |
| | 47 | server?" and "require this server?" buttons |
| | 48 | - David-Sarah (and Zooko) pointed out that "require?" is a bit harsh |
| | 49 | given our current H= ("Servers Of Happiness") share-placement code |
| | 50 | - tradeoffs between clear-and-restrictive vs confusing-but-fails-less |
| | 51 | - challenge of identifying reliability of nodes |
| | 52 | - Brian says client/gateway should expect user to teach it what sort of |
| | 53 | grid they expect, so it can bail when expectations aren't met |
| | 54 | - Shawn would prefer scheme where client measures reliability itself, |
| | 55 | chooses k/N/H to meet certain speed/cost/reliability goals |
| | 56 | |
| | 57 | == encrypted git, or revision control on tahoe == |
| | 58 | - Zack(?) is thinking about revision control on top of Tahoe, will |
| | 59 | present "big crazy idea" later when everyone is there |
| | 60 | - Brian mentioned his signed-git-revisionid project (not yet released), |
| | 61 | and how git fetch/push is fast because both sides know full revision |
| | 62 | graph and can compute missing objects in one RTT. To get this in |
| | 63 | Tahoe, we must add deep-(verify)-caps and let servers see shape of |
| | 64 | directory tree. |
| | 65 | - Lunch conversation about Monotone's mutable metadata and the problem |
| | 66 | of transferring it efficiently |
| | 67 | |
| | 68 | == grid management == |
| | 69 | |
| | 70 | non-transitive one-at-a-time invitations, transitive clique invitations, |
| | 71 | Grid Admin star config |
| | 72 | |
| | 73 | - Brian is thinking about grid setup and Accounting, and pondering a |
| | 74 | startup mode where servers issue Invitations to clients |
| | 75 | - pasting Invitation code into a web form is sufficient to get |
| | 76 | connected to grid (combines Introducer functionality with Account |
| | 77 | authorization) |
| | 78 | - probably set up bidirectional connection: when Alice accepts |
| | 79 | Invitation from Bob, both Alice and Bob can use each other's |
| | 80 | storage |
| | 81 | - three modes: |
| | 82 | - issue/accept one Invitation per link |
| | 83 | - each node needs one Invitation to join clique, then they get access |
| | 84 | to all storage servers in the clique (and offer service to all |
| | 85 | clients in the clique): grid grows one node at a time |
| | 86 | - issue: can two grids merge? or can you only accept an invitation |
| | 87 | when you aren't already in a grid? |
| | 88 | - managed grid: a central Grid Admin is the only one who can issue |
| | 89 | Invitations. When accepted, Alice can use storage of all members. |
| | 90 | - Shawn thinks a Request model is more natural: Server admin (or Grid |
| | 91 | Admin) sends ambient URL to new user, they paste it into a field that |
| | 92 | says "Request Access", this sends a Request to the server (probably |
| | 93 | containing a pubkey), the server records it, then later the server |
| | 94 | admin Accepts or Rejects the request. |
| | 95 | - Invite and Request are duals, modulo some channel and workflow |
| | 96 | variations (confidential vs authentic, who-sends-first-message) |
| | 97 | - Brian will explore how hard/feasible it is to run one workflow on top |
| | 98 | of the other: can a Request be expressed with a note saying "please |
| | 99 | send an Invitation to this public encryption key" sent to the server? |
| | 100 | |
| | 101 | == #466 new-introducer review == |
| | 102 | - Brian walked through most of the #466 new-introducer code |
| | 103 | (https://github.com/warner/tahoe-lafs/tree/466-take7) with |
| | 104 | David-Sarah and Zooko |
| | 105 | - David-Sarah found one critical security bug (signature checking |
| | 106 | failure), lots of good cleanups to recommend, tests to add |
| | 107 | - overall it looks good |
| | 108 | - Brian will make suggested cleanups and prepare for landing |
| | 109 | == Beer! == |
| | 110 | == signature consensus! == |
| | 111 | - over drinks, Brian and David-Sarah and Zooko discussed signature |
| | 112 | options (needed for #466, Accounting, non-Foolscap storage protocol, |
| | 113 | new mutable file formats) |
| | 114 | - choices: |
| | 115 | - [https://github.com/warner/python-ed25519 python-ed25519] |
| | 116 | (standalone C extension module) |
| | 117 | - [https://github.com/warner/python-ecdsa python-ecdsa] |
| | 118 | (standalone pure-Python module) |
| | 119 | - ECDSA from Crypto++ via pycryptopp |
| | 120 | - non-EC DSA (eww) |
| | 121 | - get Ed25519 into Crypto++, then expose in pycryptopp |
| | 122 | - add Ed25519 into pycryptopp (making it more than just a python |
| | 123 | binding to Crypto++, hence nicknamed "pycryptoppp") |
| | 124 | - get ECDSA from pyOpenSSL (we think it isn't exposed) |
| | 125 | - evaluation: |
| | 126 | - security: David-Sarah strongly prefers Ed25519, Zooko slightly |
| | 127 | prefers ECDSA (older, more exposure), Brian (who currently has a |
| | 128 | crush on everything 25519) slightly prefers Ed25519. Crypto++'s |
| | 129 | entropy-using signature code includes nonce-safety (entropy is |
| | 130 | hashed with message to mitigate VM-rollback failure). Ed25519 |
| | 131 | has deterministic signatures and nonce-safety. |
| | 132 | - speed: requirement is <10s startup with 100 servers (specifically, |
| | 133 | make sure the Announcement sign/verify is small compared to |
| | 134 | connection establishment time). That's sign+verify<100ms . This |
| | 135 | rules out python-ecdsa (sign+verify=330ms). Both a non-pure-python |
| | 136 | ECDSA and Ed25519 will do. A really fast primitive (optimized |
| | 137 | Ed25519 is like 20us) might enable new applications in the future |
| | 138 | (key-per-lease, key-per-write-request). |
| | 139 | - pure-python: slight preference for something that could be |
| | 140 | pure-python in the future if !PyPy could make it fast enough. |
| | 141 | Seems unlikely in the near-term for any of the options. |
| | 142 | - patents: murky, of course. !Redhat/Fedora core currently eschew |
| | 143 | all ECC, might change, might not, too bad. Not a clear |
| | 144 | differentiator between ECDSA and Ed25519. Nobody was willing to |
| | 145 | tolerate non-EC DSA (would need 4kbit keys to feel safe, not |
| | 146 | confident of hitting speed requirements). We can always back it |
| | 147 | out if it proves to be a problem (at the cost of regenerating |
| | 148 | all serverids). Hopefully the scene will settle down before we |
| | 149 | want to use it for data (which would be harder to back out). |
| | 150 | - packaging: biggest differentiator |
| | 151 | - python-ed25519: must build eggs as we did for pycrypto, need to |
| | 152 | get into debian (which has other benefits, but delays tahoe), |
| | 153 | increases build pain marginally. |
| | 154 | - python-ecdsa (too slow, ruled out): pure-python, so no need for |
| | 155 | eggs, but still need to get into debian and increases build pain |
| | 156 | - ECDSA-via-pycryptopp: easy, code is mostly done, needs final |
| | 157 | review and polish, no new dependencies. |
| | 158 | - ed25519-in-Crypto++: probably good idea in long term, but will |
| | 159 | take a while (must convince Crypto++ to change, wait for a |
| | 160 | release, then add bindings to pycryptopp). Must also wait for |
| | 161 | distributions to pick up new Crypto++. Technically no new |
| | 162 | dependencies, but increases the version requirements on an |
| | 163 | external module with a historically slow (1/yr) release cycle. |
| | 164 | - ed25519-in-pycryptopp: a bit weird (pycryptoppp), fairly fast (we |
| | 165 | control pycryptopp), no external delays. No new dependencies. |
| | 166 | - **winner: ed25519-in-pycryptopp** (aka pycryptoppp). Ed25519 wins over |
| | 167 | ECDSA with potential better security and future-coolness-enabling |
| | 168 | speed. Delivering in pycryptopp means no new dependency and no |
| | 169 | external parties to block. |
| | 170 | - future goal is to get python-ed25519 into debian, then switch Tahoe |
| | 171 | to depend on it instead. And/or once Ed25519 gets into Crypto++, |
| | 172 | remove the separate implementation from pycryptopp (i.e. remove one |
| | 173 | "p" from pycryptoppp) and have pycryptopp rely on Crypto++'s version. |
| | 174 | - also, get pycryptopp's ECDSA finished off in the ed25519-bearing |
| | 175 | release, just to have it available. |
