On Fri, May 06, 2016 at 08:59:15PM +0200, u-myfx_at_aetey.se wrote:
> On Fri, May 06, 2016 at 11:48:57AM -0400, Jan Harkes wrote:
> > I would say that is a whole lot of levels of preventing to talk to the
> > wrong guy.
> 
> Nice that this covers a whole lot of potential situations.
> Nevertheless, one example to the contrary:
> 
> There is nothing preventing an update client to happily talk
> to a wrong update server instance if the ip is spoofed and "scm"
> data on some server hosts already are inconsistent
> (iow there is a possibility of error escalation or recovery prevention).

In that case I can put your mind at easy very easily.

- There is only one update server in a realm, so a client cannot
  accidentally talk to the wrong server within the same realm.
- The update clients and update server use the 'update token' as a shared
  secret to set up their connections.

So any accidential or malicious other update server that happens to take
over the same IP as the official update server will not possess the
shared secret to succesfully fool the update client. And if it does have
the right shared secret, a serverid isn't going to save anything here.

> > 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.
...
> Of course this varies depending on the service and on the choice
> of the developer, which data is to be checked.
> 
> In current upstream Coda vice rpc2 the reference to a particular
> server is the corresponding IP number; for update clients
> the reference is also an IP number, for different services can be any
> information which the client uses for the purpose of distinguishing a
> service instance.
> 
> E.g. a server f.q.d.n would do, as long as the server knows that it is
> to be contacted as this certain f.q.d.n.
> 
> IOW depending on the service the id can be represented by any byte
> sequence, of "any" length, as appropriate for the service.
> 
> This does not matter for the RPC2 layer. Given a pointer and the data length
> it can always hash the "id" data, which will be sufficient for comparison
> of the client's and the server's idea of the server identity.
...
...
> From my perspective this is not any more of a layering violation than
> CN checking in TLS.

TLS actually checks the common name in TLS, your server ids are some
opaque blob passed up the application and are not checked by RPC2. So
they can just as easily be implemented by adding a single RPC call right
after connection setup doing something like a 'GetServerId', and then
taking action in the client based on the result.

This is actually quite close to what Coda clients do when they connect
to Coda servers, they send an RPC request to 'bind' the connection to a
specific volume, if the server claims it does not have the volume the
connection is closed.

> > > 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?
> 
> Of course I was seriously looking for the answers.

Ok here is a simple answer. The server-id would probably end up as part
of the INIT2 packet, which then turns any Coda server into a source for
an amplification attack. Someone can send INIT1 packets from a fake
origin, which then result in some very large INIT2 sent to the victim.

If you move it to the INIT4, by then the connection is already set up
and it can just as well get sent as the first RPC on the new connection.

Jan