[Cryptography] Fwd: How much data should Mesh Services see?

[Phillip Hallam-Baker]

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.

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.

The IETF list is here, conversations there are covered by Note Well.
https://www.ietf.org/mailman/listinfo/mathmesh

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.

At the moment there are three basis constructs

*Mesh*: User Alice has exactly one Mesh to which she connects all her
devices.

*Account*: 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.

*Service*: A minimally trusted Internet service that provides a point of
contact through which devices connected to a Mesh Account may be
synchronized.

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.

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.

"MeshAccount" : { "ServiceIDs" : ["alice at example.com",  "alice at example.net
"],
"KeyEncryption": "MD67-UDAY-6JTI-BVTV-ZQBE-S2L5-HXCX"
}
<Signed> MDXC-UHN2-UXXU-3MAD-QHPR-3VMA-WOXA

Where  MDXC-- is a key attesting to the account profile...


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.

The problem lies in the fact that the service needs to know some of the
contents of some of the catalogs. Specifically:

Device catalog -
    Needs to know if a ConnectionDevice has been updated or revoked.
    Needs to be able to retrieve the device entry by an index known before
the device is connected.

Contacts catalog -
    Needs to be able to determine that an inbound Mesh Message is sent by a
party authorized by the recipient.
    Need to be able to determine that an outbound message sent by the user
is not likely to be abusive.

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.

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.

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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20190919/fc505df3/attachment.htm>