search

coniks-sys / coniks-go

A CONIKS implementation in Golang
http://coniks.org
Other
116 stars 30 forks source link

How do we return the user policies as a part of user's data blob? #46

Open vqhuy opened 8 years ago

vqhuy commented 8 years ago

The discussion so far is https://github.com/coniks-sys/coniks-go/pull/29#discussion-diff-72910690.

masomel commented 8 years ago

Just a side-note, we should de-serialize the data blob to user's key, user policies before responding (it maybe looks like {"key": "...", "allow_public_lookup": true, "allow_unsigned_key_change": true} instead of {"blob": "allow_public_lookup||allow_unsigned_key_change||key"}

It seems we discussed that the server should de-serialize the data blob before responding to the client, though I voiced some privacy concerns, i.e. that the server would have more information about the type of data stored in the blob.

I think there are a few questions we need to answer about the server design to decide whether the server should deserialize the data blob. Do we want the server to be able to validate a key change whenever it receives a signed key change request (i.e. like we do in coniks-java right now, the server ensures that the signature of the request is valid)? Or should the server be completely agnostic to the data that is stored in the blob?

vqhuy commented 8 years ago

Could you please elaborate on this?

the server would have more information about the type of data stored in the blob.

The server would see either the data blob is encrypted or unencrypted, right? Is there any other information the server can obtain if we de-serialize the data blob? I think we need to refine the registration request as well as the server lookup response. Specifically, allow_public_lookup could be a part of the data blob without exposing to the server, whereas allow_unsigned_key_change could be a separate field of the request that the server's aware of it. And the lookup response would be the data blob without allow_unsigned_key_change. I think the users don't need to know about the allow_unsigned_key_change policy of others. What do you think?

masomel commented 8 years ago

The server would see either the data blob is encrypted or unencrypted, right? Is there any other information the server can obtain if we de-serialize the data blob?

I'm not sure if there is any other information the server can obtain. But what I'm trying to get at is, do we think that keeping the lookup policy private from the server is important. Is there any advantage to having the server de-serialize this information before responding to the client? This is an implementation decision we make, so we can decide either way. I'm probably overthinking this. I'm mostly just trying to flesh out all implementation details right now, I don't know if @arlolra or @Liamsi have strong feelings about this particular point.

Specifically, allow_public_lookup could be a part of the data blob without exposing to the server, whereas allow_unsigned_key_change could be a separate field of the request that the server's aware of it. And the lookup response would be the data blob without allow_unsigned_key_change. I think the users don't need to know about the allow_unsigned_key_change policy of others. What do you think?

I'm not sure about this. If we don't expect clients to verify other users' signed key change requests, then your suggestion is fine. But I was imagining that clients would verify their contacts' key change requests depending on their policy (i.e. if Bob's policy is allow_unsigned_key_change = false, my client would ensure that all of his key changes have a proper signature). Or are we only going to rely on clients monitoring their keys to detect any malicious key changes?