search

coniks-sys / coniks-go

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

[WIP] Registration should happen in epoch #189

Open vqhuy opened 6 years ago

vqhuy commented 6 years ago

Merge #191 first.

vqhuy commented 6 years ago

We started the discussion in #173. Also, iirc, we still have an open question: should the client send a key lookup first to get its index and then register with that index instead of "raw" username?

masomel commented 6 years ago

We started the discussion in #173.

Ok, I couldn't find much discussion around registrations apart from the initial post in the issue. I'm still not 100% clear on what we gain if we let the server tell us if the registration is in-epoch or not. Couldn't a malicious/misconfigured server just always tell us we're late, and never allow us to register? In other words, I don't see how this new mechanism really ensures, or gets us closer to, keeping the client in sync with the server's epochs.

should the client send a key lookup first to get its index and then register with that index instead of "raw" username?

What is the main purpose of doing this? At least in terms of privacy, I don't see much that we can gain by registering the index instead of the raw username. The server can still create mappings of the "raw" username and index at many different points in the protocol since lookups still happen with the raw username. I still find it more important for the client to generate its own salt for the commitment during registration.

vqhuy commented 6 years ago

What is the main purpose of doing this?

IIRC this is what we were trying to understand since it is implemented in both Coname and KT.

Couldn't a malicious/misconfigured server just always tell us we're late, and never allow us to register?

If the server doesn't allow us to register, it can use some simple methods like just ignoring the request? And I don't think there is a way for the server to cheat here because:

Since registration has to happen in the latest epoch, if the server receives a request to register in an outdated epoch, it should return an error, and give the client a chance to defer / re-request with exponential backoff. Alternatively, the client can set a monitoring flag to true and prematurely queue other requests until that's done.

In other words, I don't see how this new mechanism really ensures, or gets us closer to, keeping the client in sync with the server's epochs.

We use some mechanisms (e.g., Roughtime or NTP) to make sure the client have the latest STR (or whether the STR was issued on time and whatnot), same as lookup case. It's been a long time so correct me if I say something wrong.

masomel commented 6 years ago

IIRC this is what we were trying to understand since it is implemented in both Coname and KT.

Got it. If this is the case, we should certainly send Gary an email to find out more.

If the server doesn't allow us to register, it can use some simple methods like just ignoring the request? And I don't think there is a way for the server to cheat here because:

Since registration has to happen in the latest epoch, if the server receives a request to register in an outdated epoch, it should return an error, and give the client a chance to defer / re-request with exponential backoff. Alternatively, the client can set a monitoring flag to true and prematurely queue other requests until that's done.

Right, the server could always deny service. My point was that I don't see how the above mechanism of having the server return an error if it receives a registration request for an outdated epoch prevents the server from cheating. As it's currently implemented, the server just returns an ErrorOutdatedEpoch message with no other information. In order to prevent the server from cheating, I would expect that the server include non-repudiable information a client can use to check if the server is saying the truth about the epoch with an auditor.

We use some mechanisms (e.g., Roughtime or NTP) to make sure the client have the latest STR (or whether the STR was issued on time and whatnot), same as lookup case. It's been a long time so correct me if I say something wrong.

Yes, you're definitely right about this. But the clock sync'ing mechanism is independent from the registration in-epoch mechanism. My question is more, if we have a clock sync'ing mechanism in place, why couldn't we just make sure the clocks between the server and client are sync'd before the client makes a registration request and then just send the request as soon as the new epoch has started? In other words, what does the registration in-epoch mechanism add to our existing clock sync'ing?