[Mathmesh] How much data should Mesh Services see?

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 19 September 2019 15:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2F012002E for <mathmesh@ietfa.amsl.com>; Thu, 19 Sep 2019 08:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-Z4cjA0zqfj for <mathmesh@ietfa.amsl.com>; Thu, 19 Sep 2019 08:26:21 -0700 (PDT)
Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60D112000F for <mathmesh@ietf.org>; Thu, 19 Sep 2019 08:26:21 -0700 (PDT)
Received: by mail-oi1-f173.google.com with SMTP id w17so3039752oiw.8 for <mathmesh@ietf.org>; Thu, 19 Sep 2019 08:26:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7IaLxVSWbYYPPKbed93cvZldSNGsdwMECo84KH3aFd8=; b=AokuTeRTxp0EtfYG+SKn/Pff4bwesPNDhUbt9qdkFQGSOfcMTxs+VC4m+VRqj980EW HzOa9vsS4/XUfLW0K45ST6YXcZVO0rm1YhpQXQPUMbzyNucdAKcWiQkWMTzs46ygFZfp nf0dhrbq2x2+vXWbPT2cwEQNL9j0vbF8mO/bgTAzV0uyKkKIU61lS0YJSK034GWElcxo y1cwjrXxtIgyyLV2WhwpNCHOxKy/S36yWAzbLNCJ2MSpYA2qQUTA4lp1uXEeMHFPx7/L hEdQD7gTqbZSJ0KGC6Ow2is2ulLz0Q+kQoQX5MlV1W/eFOF9S+JGBL5RmTnUlAVd+tx1 8jEg==
X-Gm-Message-State: APjAAAUipYvIBTpk4cG4o4eP67HAWAru6Uln+hRfbVcF5wOMgnaEC4BS Wsr56jvC1Ygr67Lr/vxaUqXkAkNUqmoiBjcq3WfKYMV0
X-Google-Smtp-Source: APXvYqzMG9tg/w7BjLJEr3p9XoPmEWwzKCzzC/zC9bxfClpxlZNBLxtHobb1VgZFwRqRJoMva4jgMFLRTcxES1DHwQs=
X-Received: by 2002:aca:c458:: with SMTP id u85mr2785300oif.100.1568906780675; Thu, 19 Sep 2019 08:26:20 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 19 Sep 2019 11:26:09 -0400
Message-ID: <CAMm+LwgyNDanjr5kYi94rZdMA1hLc6BiQbJgEqp7Nms5JDOhpg@mail.gmail.com>
To: mathmesh@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005913e70592e9936d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/9MKRJn2qkYAEaXMVlt70j5XPTi0>
Subject: [Mathmesh] How much data should Mesh Services see?
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 15:26:25 -0000

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@example.com",  "alice@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.