(Illustration by Gaich Muramatsu)
On Fri, May 06, 2016 at 04:31:25PM +0200, u-myfx_at_aetey.se wrote: > On Fri, May 06, 2016 at 09:18:55AM -0400, Jan Harkes wrote: > > We are talking about RPC2, which is a messaging protocol between clients > > and servers that relies on shared secrets to get a common session key. > > > > If client A wants to connect to server B and somehow finds out that it > > is supposed to connect to address X port Y, and whoever 'picks up the > > phone' at that address uses the correct shared secret to complete the > > handshake, then there is no use for the instance id. > > Exactly, I would like a small change in rpc2 to be able to make use of it. I think you didn't actually read what I said there. There is no 'exactly' there where we agree on. For reference I'll copy the above text again down here. If client A wants to connect to server B and somehow finds out that it is supposed to connect to address X port Y, and whoever 'picks up the phone' at that address uses the correct shared secret to complete the handshake, then there is no use for the instance id. Where I clearly state "there is _no_ use for the instance id" and in response you say (paraphrased), "Exactly, that is why I want to add an instance id to the rpc2 handshake". > > Because if A somehow got connected to something that isn't B, then there > > is no reliable way to resolve the issue of 'how do I connect to B'. > > This is not the issue I am worried about, but rather "prevent > A from talking to B's brother C when A intended to talk to B". > > (The issue of an unavailable service is the one Coda is meant to deal > with gracefully) Oh now we're suddenly back at talking about Coda servers then? Because last time I checked only Coda clients handle unavailable servers gracefully with write-disconnected operation. Why did you bring in the auth2 and update and other server. Coda servers either have the volume the clients wants to connect to, or they do not. If the volume is not available the server returns an error and the client is expected to go away and try again later. If the server has the volume the client's request can be handled. It doesn't matter if we've got B or C, as long as they have the needed volume. > For me, if the instance is not the one the rpc2 client meant to contact, > it is wrong. There is nothing in the code which prevents this. Yes there is, the server has to run at the right ip address and the right port, and it has to use the correct shared secret when given a particular client identifier, and the the RPC2 protocols have unique values (subsystems) so you cannot send volutil commands to an auth2 daemon, and so finaly you connected to a server on the expected address/port, and it knows the shared secret and it uses the same 'subsystem', and then finally it happens to actually have (for instance) a copy of the volumeid we are trying to connect to. I would say that is a whole lot of levels of preventing to talk to the wrong guy. > You insist that when this happens, it is guaranteed to be harmless. > > I do not see any guarantee for being harmless and I doubt you > have analyzed the system exhaustively, to be able to say _never_. You aren't even clear about which 'protocol' you are talking about. vice.rpc2? auth.rpc2? volutil? update? resolution? repair? You are just handwaving about a 'server id' or 'instance id'. What is this 'ID', a single 8 bit number what the Coda servers currently prepend to volumeids? a 32-bit number? 64-bit? UUID? Maybe an X509 identifier? Signed? How about a 4096-bit PGP public key. I have given multiple concrete examples. I have exhaustively analyzed 'the system' to the point that I am convinced there is first of all no need for a server identifier. Second of all it would be a gross layering violation to stuff it into the rpc2 handshake. And finally... > Do you feel this would be expensive or risky? What would be the downsides, > besides the corresponding API extension (adding a "server instance id" > argument)? Are you seriously still saying that after all that I wrote in my previous email? JanReceived on 2016-05-06 11:49:10