yahooarchive / coname Goto Github PK

In client.proto, verifier and ratifier seem to be used interchangeably. If they actually are the same thing, let's use one or the other.

LookupProof should generalize to proofs of absence, right? Does the message structure need to be different to handle absence proofs?

Several hours of developer time were just spent debugging a livelocked test. Oh well. We really should remove all time-dependence from the testing -- is https://godoc.org/github.com/facebookgo/clock the way go, or does anybody have positive experience with some other library?

vrf proofs do not need to be recomputed for each query. They could be stored next to the profile during updates and just read from there. This would trade storage io for less cpu load. We do not necessarily want to do it, but it is totally possible and safe.

Not sure if this project is still in active development. If so, you might want to change your VRF implementation.
For details see:
coniks-sys/coniks-go#175
or
google/keytransparency#567

in https://github.com/yahoo/coname/blob/master/proto/client.proto#L111, version is confusing; for instance, it could also be used to refer to API version. I think counter is what you mean.

We have basic logging needs - support for log levels and log rotation. Should we write our own based on standard "log" package or use one the popular ones like glog, etc? Any preference?

It broke somewhere between the version I checked in when I tried to do dependency vendoring (hah, maybe should have continued) and 056e49a669ad72a638fd7d079c5b587be5b5a47f. I think a git bisect might give some insight to why. This issue is blocking as of the next time we want to change a proto file.

I would guess this is a shutdown race, either in replication, replication test, or grpc-go.

panic: assignment to entry in nil map

goroutine 1085 [running]:
google.golang.org/grpc/transport.(*http2Client).NewStream(0xc820dce620, 0x31c0efc03a8, 0xc82000e6e0, 0xc8247f7c60, 0x0, 0x0, 0x0)
    /home/uhu/go/src/google.golang.org/grpc/transport/http2_client.go:270 +0x8c7
google.golang.org/grpc.sendRequest(0x31c0efc03a8, 0xc82000e6e0, 0x31c15039f08, 0xd57028, 0xc8247f7c60, 0x31c0df3d298, 0xc820dce620, 0x9f3dc0, 0xc820f22900, 0xc821020350, ...)
    /home/uhu/go/src/google.golang.org/grpc/call.go:73 +0x9c
google.golang.org/grpc.Invoke(0x31c0efc03a8, 0xc82000e6e0, 0xaa3450, 0x10, 0x9f3dc0, 0xc820f22900, 0x9f4ae0, 0xd57028, 0xc820e28840, 0x0, ...)
    /home/uhu/go/src/google.golang.org/grpc/call.go:169 +0x86f
github.com/yahoo/coname/server/replication/raftlog/proto.(*raftClient).Step(0xc82002e138, 0x31c0efc03a8, 0xc82000e6e0, 0xc820f22900, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /home/uhu/go/src/github.com/yahoo/coname/server/replication/raftlog/proto/raftrpc.pb.go:53 +0xec

c91ef26 contains some VRF code, but things need to be figured out before I am at all comfortable using it.

In the order of priority:

1. Are all (name, vrf) pairs that pass Verfiy a bijections (meaning no collisions in either direction) under cryptographic assumptions?

2. Is the double Icart function a valid way to instantiate H1?

3. Is SHA2 a valid instantiation for the main random oracle (w.r.t length extension, for example)?

4. Is the implementation doing what we want it to be doing?

5. Is there anything faster than P384 that we could use? needs p%3==2 for Icart. The current performance is meh: 50 proofs/sec on i7-5600U with go1.5:

   BenchmarkCompute-4 200 7152502 ns/op
   BenchmarkProve-4 100 20612791 ns/op
   BenchmarkVerify-4 50 26990501 ns/op
   ok github.com/yahoo/coname/common/vrf 13.036s
   go test -bench=. 16.70s user 0.70s system 128% cpu 13.510 total

This is just a note that cnclient is not production-quality code or even close to that. We will probably want a real command-line client at some point, probably based on dename/dnmgr instead of cnclient. If you are looking for coname-specific example code, the server tests have functions for performing updates and lookups.

https://github.com/yahoo/coname/blob/master/AUTHORS#L2 says:

# This file is distinct from the CONTRIBUTORS files.
# See the latter for an explanation. 

but I could not find a CONTRIBUTORS file(s) and the related explanation... Also the first line says: This is the official list of Dename authors for copyright purposes. - maybe the AUTHORS file should be renamed to something like AUTHORS.dename for clarity?

We are probably affected by etcd-io/etcd#3699.

--- FAIL: TestKeyserverRoundtripWithoutQuorumRequirement (0.04s)
server_test.go:234: profile didn't roundtrip: != 0a146e6f6e63656e6f6e63656e6f6e63654e4f4e4345120a0a036162631203010203120f0a0378797a12085445535420343536
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
--- FAIL: TestKeyserverUpdateWithoutQuorumRequirement (0.05s)
server_test.go:234: profile didn't roundtrip: != 0a146e6f6e63656e6f6e63656e6f6e63654e4f4e4345120a0a036162631203010203120f0a0378797a12085445535420343536
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
FAIL

Currently there is a ed25519 subdirectory, but there are also imports of github.com/agl/ed25519 (ex. https://github.com/agl/ed25519/blob/master/ed25519.go#L17 , https://github.com/yahoo/coname/blob/master/keyserver/server.go#L36, https://github.com/yahoo/coname/blob/master/keyserver/deploy/make_config.go#L38). The reason for both "vendored" (embedded) directory and imported does not seem obvious (possibly historic or related to the codebase evolution?). Since Adam put his ed25519 code into golang.org/x/crypto/ed25519 - see golang/crypto@c9aef11 - should we standardize all references and imports to that "official" version? If there are no objections in general, I can send a PR for the differences in API etc.

@maditya

In the reconfiguration mess doc, it mentioned a few things that are not exactly true.

etcd/raft requires that a new replica being added must know the exact state of the cluster at the moment it is added. Similarly, replicas who are not yet aware of a recent reconfigurations are not able to receive commands from the new nodes: this means that a new node serving as a leader cannot help those replicas to catch up. Nodes not in the cluster cannot catch up with the cluster before being added -- and adding them would reduce availability.

etcd/raft does not have this requirement. You can just add node and starts that node with no configuration at all. Also replicas can receives commands from leader even if it does not know the recent configuration.

The truth is that in etcd we add additional stricter checking which are necessary in our use case. You do not have to do any checking if you do not willing to.

@andres-erbsen or @daniel-ziegler , can you please help with that? Thanks :)

As the GitHub reminder says: "Help people interested in this repository understand your project by adding a README!"

https://github.com/yahoo/coname/blob/master/cnclient/client.go#L107 should provide a DKIMProof on initial registration. This would be an email sent from the address being registered to the address being registered with the subject line containing the prefix specified in server conf and then the hash of the entry. Lack of this proof will likely cause an io.EOF on the server side prior to 5fe00a3.

example directories in /tmp: keyserver961875949 verifier958246201

I suggest to rename the subdirectory "main" in keyserver/main to something more descriptive and appropriate for the name of generated library - so that you could use the 'regular' go install -v github.com/yahoo/coname/keyserver/somethingdescriptive" command and not end up with executable "main" (or have to fall back ongo build` command).

Also, now after running go get -v github.com/yahoo/coname, you do get an executable "main" in your GOPATH/bin (or GOBIN):

$ GOPATH=/tmp/yago go get -v -u -t -x github.com/yahoo/coname/...
$ ls -l /tmp/yago/bin
total 97376
-rwxr-xr-x  1 dmitris users  11555548 Jan 11 21:53 cnclient
-rwxr-xr-x  1 dmitri users  11218892 Jan 11 21:53 deploy
-rwxr-xr-x  1 dmitris users  16354428 Jan 11 21:53 main
-rwxr-xr-x  1 dmitris users 10723040 Jan 11 21:53 protoc-gen-coname

--- FAIL: TestKeyserverUpdate-2 (1.54s)
server_test.go:399: rpc error: code = 2 desc = "timed out while waiting for ratification"

Also happens in ThreeVerifiers test on travis. I have not managed to reproduce this locally.

keyserver.step overwrites redundant updates during the same epoch. As they are still exposed to verifiers, it would be nice to also keep the for showing to clients.

All verifiers should be authenticated on connection level and they should not be allowed to submit signatures under any other id than their own. We would like to implement this using client certificates (with CommonName=verifier id), but it is blocking on grpc/grpc-go#111.

Hey folks! Interested in your work. Could summarize some of the changes being considered, compared to dename and CONIKS? (I'd also like to hear what quorum algorithms you're considering, now.)

Thanks!

shouldn't LookupProof be signed by the keyserver so that it can be used by the client to prove that a keyserver is misbehaving? Ex: if a keyserver returns a malicious tree proof and the client detects this, it can be used as evidence of compromise.

This affects raftlog, verifier, and keyserver. We need tests that make sure that the in-memory state is correctly loaded from disk on startup.

The JSON marshalers and unmarshalers our generate script produces using the latest gogoproto do not pass the autogenerated tests (they fail by trying to unmarshal an enum as if it had been encoded as an int, but it is actually encoded as a string). I don't know what causes this.

OTOH, the only part where andres-erbsen/protobuf differs from gogo/protobuf is the jsonpb package. In particular, I believe this means that we do not need to use my fork for code generation, only for json marshaling (by sed-patching the jsonpb in the generated files). This will hopefully let us catch the next issue of this kind right when gogoproto introduces it. Even better, if we play it well, then we might be able to upstream the jsonification patch ("prefer specialized Marshal/Unmarshal implementations to the generic" can sound pretty well, even though we use this in a hacky way in our project).

How urgent is updating gogoproto compared to working on cluster membership changes?

This issue is for tracking planned renames of packages and interfaces.

• server -> keyserver, because server is really not descriptive.
• server.VerifierBroadcast, server.WaitingRoom -> separate packages in server/internal/ (internal folder spec)
• coname -> e2eks when it is known what the final name will be AND that the coname design will be used to implement that.