[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.
- [Mathmesh] How much data should Mesh Services see? Phillip Hallam-Baker