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?

Jan