<div dir="ltr"><div class="gmail_default" style="font-size:small">I sent this to the IETF Mesh discussion list but would appreciate folk here joining in the discussion as there is an important and difficult problem at issue here. I have just rewritten the Mesh so that there is now almost no information on the service except for the minimal amount of metadata required to enable the service to perform the tasks delegated to it by the user. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The interactions supported by the Mesh do require some form of drop-box type functionality and at least a part of that functionality must be in the cloud. I can reduce the degree of trust in that service to the bare minimum but while I can prevent confidentiality breaches and provide strong guarantees of integrity, the service is by its nature always going to be a point of vulnerability for traffic analysis, metadata and service attacks.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The IETF list is here, conversations there are covered by Note Well.</div><div class="gmail_default" style="font-size:small"><a href="https://www.ietf.org/mailman/listinfo/mathmesh">https://www.ietf.org/mailman/listinfo/mathmesh</a>  <br></div><div class="gmail_quote"><br><div dir="ltr"><div style="font-size:small">I am almost done getting the 3.0 reference code to run. This was a very substantial rewrite as it meant using the features I intended to build on top of the Mesh to secure the Mesh itself.</div><div style="font-size:small"><br></div><div style="font-size:small">At the moment there are three basis constructs</div><div style="font-size:small"><br></div><div style="font-size:small"><b>Mesh</b>: User Alice has exactly one Mesh to which she connects all her devices.</div><div style="font-size:small"><br></div><div style="font-size:small"></div><div style="font-size:small"><b>Account</b>: Alice can create as many Mesh Accounts as she likes and they are each insulated from every other account. A device may be connected to multiple accounts. <br></div><div style="font-size:small"><br></div><div style="font-size:small"><b>Service</b>: A minimally trusted Internet service that provides a point of contact through which devices connected to a Mesh Account may be synchronized.</div><div style="font-size:small"><br></div><div style="font-size:small">It is not necessary for Alice to create multiple Meshes to protect her privacy because it is a purely personal resource that is only used for the management of devices and accounts.<br></div><div style="font-size:small"><br></div><div style="font-size:small">A Mesh account may be connected to multiple services but only one of the services is authoritative. The user may change their service at any time. I have not implemented a transition protocol but since every Mesh contact exchange is bound to the account UDF fingerprint, we can easily effect a change of service by simply dropping a signed assertion into some sort of public log.</div><div style="font-size:small"><br></div><div style="font-size:small">"MeshAccount" : { "ServiceIDs" : ["<a href="mailto:alice@example.com" target="_blank">alice@example.com</a>", 

"<a href="mailto:alice@example.net" target="_blank">alice@example.net</a>"],</div><div style="font-size:small">"KeyEncryption": "MD67-UDAY-6JTI-BVTV-ZQBE-S2L5-HXCX"<br></div><div style="font-size:small">}</div><div style="font-size:small"><Signed> MDXC-UHN2-UXXU-3MAD-QHPR-3VMA-WOXA<br></div><div style="font-size:small"><br></div><div style="font-size:small">Where 

MDXC-- is a key attesting to the account profile...</div><div style="font-size:small"><br></div><div style="font-size:small"><br></div><div style="font-size:small">OK so the idea of the service is that it just holds a sequence of DARE catalogs which are just lists of envelopes with a header, encrypted blob of data and a trailer.</div><div style="font-size:small"><br></div><div style="font-size:small">The problem lies in the fact that the service needs to know some of the contents of some of the catalogs. Specifically:</div><div style="font-size:small"><br></div><div style="font-size:small">Device catalog - </div><div style="font-size:small">    Needs to know if a ConnectionDevice has been updated or revoked.</div><div style="font-size:small">    Needs to be able to retrieve the device entry by an index known before the device is connected.</div><div style="font-size:small"><br></div><div style="font-size:small">Contacts catalog -</div><div style="font-size:small">    Needs to be able to determine that an inbound Mesh Message is sent by a party authorized by the recipient.</div><div style="font-size:small">    Need to be able to determine that an outbound message sent by the user is not likely to be abusive.</div><div style="font-size:small"><br></div><div style="font-size:small">Filtering inbound messages is relatively straightforward as we can easily require the message envelope to carry whatever information we like. We could even require it to contain a token of the form 'Alice is allowed to speak to Bob', i.e. a capability. I think it more likely however that we would want to enable anyone to communicate with anyone else without requiring every possible link be represented as a capability. Not least because I don't think Bob wants Alice to know precisely what those capabilities are.</div><div style="font-size:small"><br></div><div style="font-size:small">So I think the wrapper of a Mesh Message from Bob to Alice is going to be limited to a signature by Alice's device and an authentication chain plus the strong address of Bob, i.e. the service address plus the mesh fingerprint of the account.</div><div style="font-size:small"><br></div><div style="text-align:left;font-size:small">Which means that the contacts directory is going to need to include some unencrypted information that allows it to 1) locate Bob's entry in the contact catalog using his strong address(es) as index and 2) determine if the strong address is authorized for the operation in question.</div><div style="font-size:small"><br></div><div style="font-size:small"><br></div><div style="font-size:small">I am aware that there is something of an efficiency issue here and it is probably not desirable for an Internet service to be constantly parsing structures as complex as a DARE Container every time a message is received. But this is fairly easy to address using a 'hot index' file which the service can compute from the container as an offline task. We can now perform a lookup in O(1+u) time where u is the number of updates written to the container since the index was calculated. The container file format even allows such an index to be written to the end of the container itself.</div></div>
</div></div>