[Mathmesh] Status

[Phillip Hallam-Baker <[e-mail]>]

I am currently trying to complete the refactoring of the Mesh so that
everything is built on DARE. This has allowed me to cut the amount of code
by 50%.

One issue that I have been grappling with is how device connection requests
are handled and how this ties in with the general client authentication
mechanism. And there is an interesting set of constraints.

Recall that we don't trust manufacturer generated keys. So the keys that a
device uses in the context of the Mesh are different from the ones it
shipped with (or generated locally). The Mesh keys are the sum of the
device and administrator contributions.

This creates a challenge: How does a device complete a connection request
to obtain the administrator contribution? The device cannot authenticate as
a Mesh connected device until it is connected.


I have come up with the following solution:

*  Created a new spool 'local' for outbound messages that are to be
collected from the service rather than forwarded.

A device requesting a connection to [e-mail] posts a
RequestConnection to example.com

The service creates an  AcknowledgeConnection message that allows the
witness value to be calculated and returns that to the device requesting
connection and appends it to alice's inbound spool.

Alice accepts or rejects the connection and posts a RespondConnection to
her local spool.

The device polls for the completion message response specifying a
transaction identifier contained in  AcknowledgeConnection


So all that is left, is a means to calculate the  transaction identifier. I
am considering using the UDF of the MessageID of the  AcknowledgeConnection
message. Since this is server generated, it is going to take collusion
between the device and service to leverage this for some form of DoS
attack. And the service can't perform a DoS attack by definition.

I am wondering if I should generalize this in some way so that when there
is a chained transaction, the identifier of the next message in the
sequence is determined by the immediately preceding message with the
possible incorporation of a nonce. This approach seems very fluent.

One nice side benefit to this is that we can support pending messages
easily. The response to a connection request in an enterprise setting could
well be 'I need to check' so we want to have the option of posting Pending
and tell the requester what to wait on. So our CSP traces are:

Pending* -> (Accept | Reject)

Since the pending messages are moot once Accept or Reject are posted, we
can use the same MessageID for all of these and just have the service
return the last one.