Message in the Announcement?
liamsi opened this issue · comments
For the timestamp server it would be neccessary to send the message to be signed in the Announcment phase already.
The reason is that the in the timestamp service the root node would send down the current timestamp (along with the other data to sign off). The children should only sign the statement if the timestamp presented by the root (somewhat) corresponds with their individual view of the current time.
This could easily be realized using the RegisterAnnouncementHook message and by sending the data to be signed in the Announcement. The nodes could use the bitmask exception mechanism to say, that they won't participate in the signing process. We would need this for NSDI but this could be interesting for cosi in general. So I'll leave this issue here and submit a PR if the timestamp server wont't get too "hacky".
OK, I see, we currently don't even use the bitmask mechanism for cosi which is also would be needed.
I've made a branch when working with @nikirill doing a CoSi with a verification function with data that gets passed in the announcement already:
dedis/cothority -> branch swupdate_cosi
Look at protocols/swupdate/cosi_update.go
We finally did not use it since we went to others directions for the paper but it's useful here I guess.
OK, I see, we currently don't even use the bitmask mechanism for cosi which is also would be needed.
This might be somehow related to #11 and #10. Although the use-case is different: The servers aren't faulty, they are live but don't accept the data and refrain from signing.
We can discuss to use regular cosi as it is first and skip the data validation+exception handling.
We finally did not use it since we went to others directions for the paper but it's useful here I guess.
Cool thanks a lot. Will have a look into it.
dedis/cothority -> branch swupdate_cosi
Look at protocols/swupdate/cosi_update.go
This looks good/exactly what I had in mind (besides the go-routine for the verification; it makes sense for the reproducible build case but not if data is just a timestamp)!
Thinking about it further I have a general remark/question: with this implementation the root node becomes a single point of failure in the sense that it can easily DoS the whole system (or some not too far down child-node could do the same) by always lying that all its children didn't participate, or am I missing sth?
I think this issue is related to the exception mechanism that is not defined yet. For example, in the current CoSi, the root can simply do nothing and also be a single point of failure, but the client will know (because of a timeout or empty signature) so it will try with a new root. Here, the client will see that all children have failed which is also highly suspicious; and others nodes should "see" the final signature to detect the misbehaving root. One idea was to link signatures together so if a signature present a lot of nodes failing, the other nodes know something is wrong.
In general, there's no clear scheme how cosi-nodes relate to each other; a lot of bad stuff can happen currently.
As long as we don't handle the exception stuff, there's not much to care about :/
OK, I'll ignore all edge cases an assume the root is honest :-( ... Hackedyhack, at least for now.
can this be closed?
I think so too for the moment. Closing it.