Skip to content

Developer Meeting Notes

Jump to bottom
Marcela Melara edited this page Dec 5, 2016 · 8 revisions

Nov 17

Agenda:

  • #120 & #121

  • Merged (#120 repurposed for vrf key rotating)

  • #114 quick look

  • merged (#123)

  • #127: create 2 separate pulls

  • #125: Maintaining 2 sets of documentation (godocs and Readme.md)?

  • document binary usage in README.md * should have three, bot, keyserver, client * need to add README to bots pkg

  • go api docs in godoc * this implies removing merkletree/README.md

  • Finalize the first release:

  • three PRs left (documentation + test-client + optional reg bot use in server)

  • one test-server and everyone uses the test-client for registration etc. --> 1-minute epoch length

  • Huy's note: Idea on VRF key rotation:

  • using 1 VRF key and have a policy like: the PAD will rotate the VRF key every N epochs

  • A new VRF key is created by using a KDF from previous key, with tree nonce. Do we care about future secrecy in this case? I guess no. * Security? Need review of Joseph and Michael ?

  • Private key leakage (both sigining key & VRF key)? how to deal with that? Is this separate from VRF key rotation? 

  • Marcela: Looking ahead - VRF for coniks-go & coniks-java?

  • this can wait till after the first release

  • Issue for go-VRF: #128

  • Add a sentence to each directory/package; double-check documentation here: https://godoc.org/github.com/coniks-sys/coniks-go

  • Interesting attack to think about (received via email as question):

  • CONIKS clients are expected to continuously “online” check the consistency of the server. If the server is malicious, it can temporary “block” the client check with a simple excuse like “service maintenance” while equivocate a different bindings to other’s query temporarily. On the next epoch, It can replace the malicious bindings with the old one and re-enable client check. In this situation, the other clients and other Identity Provider see nothing malicious since they receive the correct STR chain, the owner also cannot tell anything different apart from the fact that their Identity Provider was “maintaining” for an epoch. Does your design to prevent this situation (except that assumption for clients to be online and check every epoch)? A straight forward way to prevent this problem is to convert the leaf of CONIKS server tree into append-only as well (with a hash chain and commit it along with the STR).

  • discussion if this is a real attack or not:

  • This attack should be detected by the victim when it monitors its own binding and checks missed epochs

  • Each key change should generate a new TB --> promise wouldn't be fulfilled in the next epoch

  • Clients should have a key change policy for other clients (i.e. accept new keys with/without authorizing signature)

Nov 3

Agenda:

  • Review current PRs

  • #74 is getting kinda large again: do we want to split this PR into one per operation?

  • Polishing code:

  • Temporarily remove cgo library until we address #101? * Move out of master since very incomplete

  • Temporarily remove storage/kv out of master * Keep in master since API is already in used in key server

  • Finish API documentation:

  • keyserver * c633

  • util * c633

  • bots * masomel

  • Plan for 0.2.0 release (focus mostly on the protocol & client-side?):

  • Monitoring( in missed epochs?) & KeylookupInEpoch ops

  • Db hooks * make part of protocol

  • Extension architecture. TB & DB hook extension

  • Close #4, #32, #45, #70, #81, #89, etc

  • Write IETF-style specifications for the various components

  • Protocols

  • Account Verification Protocol

  • Merkle tree & PAD

  • Crypto: VRF

  • Which VRF implementation should we use?

  • Signal's design has a formal specification --> should we implement this design? * It should be very similar to what we are already using.  * Advantages: There is a extensive spec. already which is currently reviewed by the community; chances are good that this will be maintained etc.

  • coniks-java:

  • Is this implementation being used?

Oct 21

Agenda:

  • Move long specification documents in #86 to coniks.org? Move account verification protocol spec in bots to coniks.org? Follow Tor spec format? Have this done by 0.1.0?
  • Split up API documentation
  • Import third-party libs instead?
  • Can we still complete #88 by Oct 31, if not, how can we add persistent storage on time?
  • Revised release timeline:
  • Oct 24th: merge #74
  • Oct 26th: merge #93
  • Oct 30th: merge API docs: #103, #105...
  • Oct 31st: release 0.1.0

Oct 13

Agenda:

  • Possible client registraion attacks (see https://etherpad.wikimedia.org/p/coniks-client-protocols))

  • Review current PRs

  • DB hooks for protocol package: export APIs?

  • lookup in epoch

  • reconstruct the pad from db -> load directory from db

  • store TB

  • store latest STR: e.g., DirectoryUpdate(db kv.DB, ...) -> probably have to export pad field in ConiksDirectory struct -> do we want this? * No, we don't want this since we would have to expose private keys, raw user data

  • First release timeline:

  • Oct 12th: merge #99

  • Oct 18th: merge #74 & #86

  • Oct 20th: merge #93

  • Oct 25th: merge #88

  • Oct 31st: release 0.1.0

Sep 22

Agenda:

  • Auditors: language, library

  • Synchronize between auditors and the key server? Raft algorithm? How is CoSi doing?

  • Collectively work on #82 / #86

  • APB: document hacking on TM with github OTR

  • golang client

  • client library

  • coniksclient command line interface

  • this informs the api to expose to cgo

  • Does the client need an initial STR "baked in"? (prevent re-use of an "old" registration)

  • Possible attacks:

  • username is registered at an earlier epoch, then removed, can the server equivocate? Can this be detected via auditors? The only way that clients can know about the equivocation is to verify the proof itself. What exactly is "the proof"? I'm still not sure this can't be detected by querying auditors.

  • Auditor distribution: consensus based? partitioning attacks? We should open an issue for this.

Sep 1

Agenda:

  • Pulls

  • #74 is blocker to release

  • #68 general vs specific (reg proxy) limitations (done)

  • CoSi integration - how would such a protocol extension look like? how does it interoperate with existing features such as TBs and auditors?

  • for tbs, prefix bits or send to different endpoints to distinguish what's being signed

  • collusion? (can someone summarize?)

  • Organize open issues by milestone

  • Start with 0.1.0 for initial release (done)

  • Client failure modes - what to do if the CONIKS server is unreachable? early (small) user/usability tests for that case?

  • (huy's note - just write down my thoughts): for TM, it could be fall back on the current key verification mechanism

  • Question: What if the client has never done any verification of the key (not even SMP or manual)?

  • UI/UX: a slider for user to choose the security level (much like Tor Browser)

  • Server system requirements

  • Intially, relax server availability requirements

  • Replication seems too cumbersome given the current user base size

  • Possibly run separate servers for different protocols

  • Some "initial" discussions over #30  & #17 - multiple devices

  • possibly use instance tag from OTRv3 for device IDs

  • [email protected]/twitter+deviceId   (everthing after / is ignored until we fix #17)

  • Plan for the first pre-release of coniks-go

  • What happens when we hit loadedEpochs limit?

  • Include the db backend hook in this first release (e.g. https://github.com/keybase/go-merkle-tree/blob/master/interfaces.go)) 

  • For first version: just keep everything in memory and dump it regularly to a blob

  • Agreement on #70?

  • document client operations before trying to design the api to expose from the server (arlo's wish) -> Readme.md in client package

  • Meeting 30 min later

Clone this wiki locally