On Fri, May 06, 2016 at 11:48:57AM -0400, Jan Harkes wrote:
> 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:
> > > 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.

Trust me I did read. :)

> 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".

This is not what I wrote.

Trying to summarize:

I say:
======
- It is DESIRABLE to verify the service instance at current rpc2 handshake,
  BECAUSE there is no guarantee that talking to a wrong instance
  is harmless.

  This is BASED ON my perception of secure design.

- (Unfortunately) there is no place for the service instance id in the
  current rpc2 handshake.

- This can be improved and I want to create such a place and add the
  missing piece of data and the verification.

I perceive that you say: (among others in this letter below)
========================
- It is NOT NECESSARY to verify server instance at rpc2 handshake,
  BECAUSE in all current uses of rpc2 the upper layers of the protocols
  ensure that there will be no harm ever caused by talking to a wrong
  instance.

  This is BASED ON your exhaustive analysis of the interaction
  between the different parts of the code.

I am now taking your word
=========================
for the analysis of the implications, exhaustive or not.

It looks like the matter does not deserve any more discussion,
because I am convinced that it is of no immediate importance.

There is no point in fixing potential problems when we have more
tangible stuff to take care of.

I am still commenting your letter below, not for any continuation
of the discussion but for a casual reader.

> > 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.

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).

I agree though that this is unlikely to pose any immediate problem
in practice.

> You aren't even clear about which 'protocol' you are talking about.
> vice.rpc2? auth.rpc2? volutil? update? resolution? repair?

The use of an extra "server id" argument is applicable to all services,
with whatever form the "id" can have, if any (auth2 is a nice example
of a service where talking to a "wrong" guy does not do any harm,
the client can even connect to all instances at once without
caring which one replies first).

> 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.

Ok, let's go into the details.

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.

> 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...

I take you word about the protection existing in the upper layers.

The layering violation is a serious argument, but as long as the
"service instance id" data remains opaque to rpc2, does this constitute
any violation?

The specification of the rpc2 connection handshake would thus change
from "checking the shared secret of the peer" to "checking the shared
secret of the peer and of the server identification blob".

>From my perspective this is not any more of a layering violation than
CN checking in TLS.

> > 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.

Thanks for your comments Jan.

Regards,
Rune