Internet DRAFT - draft-hallambaker-mesh-architecture
draft-hallambaker-mesh-architecture
Network Working Group P. M. Hallam-Baker
Internet-Draft ThresholdSecrets.com
Intended status: Informational 28 June 2023
Expires: 30 December 2023
Mathematical Mesh 3.0 Part I: Architecture Guide
draft-hallambaker-mesh-architecture-22
Abstract
The Mathematical Mesh is a Threshold Key Infrastructure that makes
computers easier to use by making them more secure. Application of
threshold cryptography to key generation and use enables users to
make use of public key cryptography across multiple devices with
minimal impact on the user experience.
This document provides an overview of the Mesh data structures,
protocols and examples of its use.
[Note to Readers] Discussion of this draft takes place on the
MATHMESH mailing list (mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 December 2023.
Hallam-Baker Expires 30 December 2023 [Page 1]
Internet-Draft Mesh Architecture 3.0 June 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Related Specifications . . . . . . . . . . . . . . . . . 7
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 8
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. The Device Management Challenge . . . . . . . . . . . . . 10
3.2. Exchange of trusted credentials. . . . . . . . . . . . . 11
3.3. Application configuration management . . . . . . . . . . 11
3.4. Mesh Service Provider . . . . . . . . . . . . . . . . . . 12
3.5. The Mesh as platform . . . . . . . . . . . . . . . . . . 12
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Enterprise Deployment . . . . . . . . . . . . . . . . . . 13
4. User Experience . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Creating a Mesh Account . . . . . . . . . . . . . . . . . 13
4.1.1. Encrypting and Decrypting files. . . . . . . . . . . 15
4.1.2. Catalogs . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Adding devices . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 18
4.2.2. PIN Connection . . . . . . . . . . . . . . . . . . . 18
4.2.3. Making use of the new device . . . . . . . . . . . . 20
4.2.4. Applications . . . . . . . . . . . . . . . . . . . . 20
4.2.5. Threshold Key Devices . . . . . . . . . . . . . . . . 21
4.3. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Contact exchange . . . . . . . . . . . . . . . . . . 23
4.3.2. Confirmation service . . . . . . . . . . . . . . . . 26
4.4. Encryption Groups . . . . . . . . . . . . . . . . . . . . 27
4.5. Deleting Devices . . . . . . . . . . . . . . . . . . . . 29
4.6. Escrow and Recovery . . . . . . . . . . . . . . . . . . . 30
4.7. Future Directions . . . . . . . . . . . . . . . . . . . . 31
4.7.1. Device Disconnection . . . . . . . . . . . . . . . . 31
4.7.2. Service Transition . . . . . . . . . . . . . . . . . 31
4.7.3. Threshold User Account . . . . . . . . . . . . . . . 32
4.7.4. Threshold Group Administration . . . . . . . . . . . 32
Hallam-Baker Expires 30 December 2023 [Page 2]
Internet-Draft Mesh Architecture 3.0 June 2023
4.7.5. Synchronous Messaging . . . . . . . . . . . . . . . . 33
4.7.6. Social Media . . . . . . . . . . . . . . . . . . . . 33
5. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Best Practice by Default . . . . . . . . . . . . . . . . 34
5.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 35
5.3. Threshold Decryption . . . . . . . . . . . . . . . . . . 35
5.4. Threshold Key Generation . . . . . . . . . . . . . . . . 36
5.5. Threshold Signature . . . . . . . . . . . . . . . . . . . 36
5.6. Data At Rest Encryption . . . . . . . . . . . . . . . . . 37
5.6.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 37
5.6.2. Dare Sequence . . . . . . . . . . . . . . . . . . . . 37
5.7. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 38
5.7.1. Friendly Names . . . . . . . . . . . . . . . . . . . 39
5.7.2. Encrypted Authenticated Resource Locators . . . . . . 39
5.7.3. Secure Internet Names . . . . . . . . . . . . . . . . 40
5.8. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 40
6. Mesh Architecture . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.1. Account . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.2. Device . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.3. Service . . . . . . . . . . . . . . . . . . . . . . . 45
6.2. Stores . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 47
6.3. Mesh Service Protocol . . . . . . . . . . . . . . . . . . 48
6.3.1. Protocol Interactions . . . . . . . . . . . . . . . . 49
6.4. The Access Catalog . . . . . . . . . . . . . . . . . . . 49
6.5. Mesh Messaging Protocol . . . . . . . . . . . . . . . . . 50
6.6. Using the Mesh with Applications . . . . . . . . . . . . 52
6.6.1. Future Applications . . . . . . . . . . . . . . . . . 53
7. Security Considerations . . . . . . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53
10. Normative References . . . . . . . . . . . . . . . . . . . . 54
11. Informative References . . . . . . . . . . . . . . . . . . . 56
1. Introduction
The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure (TKI)
that uses cryptography to make computers easier to use. This
document describes version 3.0 of the Mesh architecture and
protocols.
In 1977, Public Key cryptography laid out a powerful proposition: If
Alice and Bob have private keys on their devices and each knows the
public key of the other, Alice and Bob can communicate with
confidentiality and integrity. The realization of this proposition
at Internet scale was vested in a technology called Public Key
Hallam-Baker Expires 30 December 2023 [Page 3]
Internet-Draft Mesh Architecture 3.0 June 2023
Infrastructure (PKI) whose principal function is to provide a
trustworthy means by which Alice and Bob can discover each other's
public key.
Yet despite the power of PKI, Internet security remains a work in
progress. While PKI has proved an effective means of authenticating
services to users, attempts to apply PKI to the equally important
task of authenticating users to services and securing data at rest
have been confined to the margins. One critical reason for that
failure is that _Public_ Key Infrastructure has only provided
effective tools for managing _public_ keys. If we are to achieve
comprehensive Internet security, we must provide every user with the
ability to manage _private_ keys across their devices with zero
effort on their part.
Threshold cryptography is a sub-field of public key cryptography that
defines operations on cryptographic keys, including operations on
private keys. Threshold cryptography allows Key generation and key
use operations may be split between multiple devices. These tools
make zero effort management of private keys practical.
The Mesh is a TKI that addresses the three principal concerns that
have proved obstacles to the use of end-to-end security in computer
applications:
* Device management.
* Exchange of trusted credentials.
* Application configuration management.
The infrastructure developed to address these original motivating
concerns can be used to facilitate deployment and use of existing
security protocols (OpenPGP, S/MIME, SSH) and as a platform for
building end-to-end secure network applications. Current Mesh
applications include:
* Multi-factor authentication and confirmation
* Credential management
* Bookmark/Citation management
* Task and workflow management
A core principle of the design of the Mesh is _autonomy_. That is
each user has full control over their digital environment and is
their own source of authority. They may choose to delegate that
Hallam-Baker Expires 30 December 2023 [Page 4]
Internet-Draft Mesh Architecture 3.0 June 2023
authority to another to act on their behalf (i.e. a Trusted Third
Party) and they may choose to surrender parts of that authority to
others (e.g. an employer) without surrendering their autonomy.
Delegation of authority is always for limited times and limited
purposes.
Thus, from the user's point of view, the Mesh is divided into two
parts: The part of the Mesh that belongs to them and everything else.
As with the Internet, which is a network of networks, a Mesh of
Meshes has certain properties that are similar to those of its
constituent parts and some that are quite different.
This document is not normative. It provides an overview of the Mesh
comprising a description of the architecture, and a discussion of
typical use cases and requirements. The remainder of the document
series provides a summary of the principal components of the Mesh
architecture and their relationship to each other.
Normative descriptions of the individual Mesh encodings, data
structures and protocols are provided in separate documents
addressing each component in turn.
The currently available Mesh document series comprises:
I. Architecture (This document.) Provides an overview of the Mesh
as a system and the relationship between its constituent parts.
II. Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. Describe
s the UDF format used to represent cryptographic nonces, keys and
content digests in the Mesh and the use of Encrypted Authenticated
Resource Locators (EARLs) and Strong Internet Names (SINs) that
build on the UDF platform.
III. Data at Rest Encryption [draft-hallambaker-mesh-dare]. Describ
es the cryptographic message and append-only sequence formats used
in Mesh applications and the Mesh Service protocol.
IV. Schema Reference [draft-hallambaker-mesh-schema]. Describes the
syntax and semantics of Mesh Profiles, Catalog and Spool Entries
and Mesh Messages and their use in Mesh Applications.
V. Protocol Reference [draft-hallambaker-mesh-protocol]. Describes
the Mesh Service Protocol.
VI. Reliable User Datagram [draft-hallambaker-mesh-rud]. Describes
the Mesh presentation and transport layer.
VII Mesh Callsign Service [draft-hallambaker-mesh-callsign]. Describ
Hallam-Baker Expires 30 December 2023 [Page 5]
Internet-Draft Mesh Architecture 3.0 June 2023
es issue and use of Mesh callsigns.
VIII Cryptographic Algorithms
[draft-hallambaker-mesh-cryptography] Describes the cryptographic
algorithm suites used in the Mesh and the implementation of Multi-
Party Encryption and Multi-Party Key Generation used in the Mesh.
IX Notarized Signatures [draft-hallambaker-mesh-notarization] Descri
bes the cross notarization of DARE sequences to prevent rollback
attacks.
XIII. Security Considerations [draft-hallambaker-mesh-security] Des
cribes the recommended and required algorithm suites and the
security considerations for the Mesh protocol suite.
The following documents describe technologies that are used in the
Mesh but do not form part of the Mesh specification suite:
XX. The Trust Mesh [draft-hallambaker-mesh-trust]. Describes the
social work factor metric used to evaluate the effectiveness of
different approaches to exchange of credentials between users and
organizations in various contexts and argues for a hybrid approach
taking advantage of direct trust, Web of Trust and Trusted Third
Party models to provide introductions.
JSON-BCD Encoding [draft-hallambaker-jsonbcd]. Describes extensions
to the JSON serialization format to allow direct encoding of
binary data (JSON-B), compressed encoding (JSON-C) and extended
binary data encoding (JSON-D). Each of these encodings is a
superset of the previous one so that JSON-B is a superset of JSON,
JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C.
DNS Web Service Discovery
[draft-hallambaker-web-service-discovery]. Describes the means by
which prefixed DNS SRV and TXT records are used to perform
discovery of Web Services.
Threshold Modes in Elliptic Curves [draft-hallambaker-threshold]. De
scribes threshold key generation and key agreement operations for
the Ed25519, Ed448, X25519 and X448 elliptic curves.
The following documents describe aspects of the Mesh Reference
implementation:
Mesh Developer [draft-hallambaker-mesh-developer]. Describes the
reference code distribution license terms, implementation status
and currently supported functions.
Hallam-Baker Expires 30 December 2023 [Page 6]
Internet-Draft Mesh Architecture 3.0 June 2023
Mesh Platform [draft-hallambaker-mesh-platform]. Describes how
platform specific functionality such as secure key storage and
trustworthy computing features are employed in the Mesh.
2. Definitions
This section presents the related specifications and standards on
which the Mesh is built, the terms that are used as terms of art
within the Mesh protocols and applications and the terms used as
requirements language.
2.1. Related Specifications
Besides the documents that form the Mesh core, the Mesh makes use of
many existing Internet standards, including:
Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic
algorithms for Mesh implementations are specified in
[draft-hallambaker-mesh-cryptography].
In addition, Mesh Devices used to administer non-Mesh applications
require support for the cryptographic algorithm suites relevant to
the application.
Transport All Mesh Services make use of multiple layers of security.
Protection against traffic analysis and metadata attacks are
provided by use of Transport Layer Security [RFC5246]. At
present, the HTTP/1.1 [RFC7231] protocol is used to provide
framing of transaction messages.
Encoding All Mesh protocols and data structures are expressed in the
JSON data model and all Mesh applications accept data in standard
JSON encoding [RFC7159]. The JOSE Signature [RFC7515] and
Encryption [RFC7516] standards are used as the basis for object
signing and encryption.
2.2. Defined Terms
TBS
2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Hallam-Baker Expires 30 December 2023 [Page 7]
Internet-Draft Mesh Architecture 3.0 June 2023
2.4. Implementation Status
The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer].
The examples in this document were created on 28-Jun-23 5:01:01 PM.
Out of 250 examples, 50 failed.
3. Requirements
The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure that
uses cryptography to make computers easier to use.
For several decades, it has been widely noted that most users are
either unwilling or unable to make even the slightest efforts to
protect their security, still less those of other parties. Yet
despite this observation being widespread, the efforts of the IT
security community have largely focused on changing this user
behavior rather that designing applications that respect it. Real
users have real work to do and have neither the time nor the
inclination to use tools that will negatively impact their
performance.
The Mesh is based on the principle that if the Internet is to be
secure, secure use of applications must become effortless. Rather
than beginning the design process by imagining all the possible modes
of attack and working out how to address these as best as possible
with least inconvenience to the user, we must reverse the question
and ask how much security can be provided without requiring any
effort whatsoever from the user. This principle is called*Zero
Effort Security*.
Today's technology requires users to put their trust in an endless
variety of devices, software and services they cannot fully
understand let alone control. Even the humble television of the 20th
century has been replaced by a 'smart' TV with 15 million lines of
code whose undeclared capabilities may well include placing the room
in which it is placed under continuous audio and video surveillance.
Every technology deployment by necessity requires some degree of
trust on the owner/user's part. But this trust should not compromise
the user's autonomy. Delegation of trust should be limited and
subject to accountability. If manufacturers continue to fail in this
regard, they risk a backlash in which users seek to restore their
rights through litigation, legislation or worst of all, simply not
buying more technology that they have learned to distrust through
their own experience.
Hallam-Baker Expires 30 December 2023 [Page 8]
Internet-Draft Mesh Architecture 3.0 June 2023
The Mesh is based on the principle of radical distrust, that is, if a
party is capable of defecting, we assume that they will. As the
Russian proverb goes: ???????, ?? ????????: _trust, but verify_.
In the 1990s, the suggestion that 'hackers' might seek to make
financial gains from their activities was denounced as 'fear-
mongering'. The suggestion that email or anonymous currencies might
be abused received a similar response. Today malware, ransomware and
spam have become so ubiquitous that they are no longer news unless
the circumstances are particularly egregious. In 1949, Edward A.
Murphy Jr. proposed his now eponymous law which states, 'Anything
that can go wrong will go wrong'. We must now apply a similar
principle to Internet security: 'Anything that can be made to go
wrong is already being made to go wrong and will only get worse until
something is done to stop it.'
We must dispense with the notion that it is improper or impolite to
question the good faith of technology suppliers of any kind whether
they be manufacturers, service providers, software authors or
reviewers. Modern supply chains are complex, typically involving
hundreds if not thousands of potential points of deliberate or
accidental compromise. The technology provider who relies on the
presumption of good faith on their part risks serious damage to their
reputation when others assert that a capability added to their
product may have malign uses.
Radical distrust means that we apply the principles of least
principle and accountability at every level to the design of the
Mesh:
* Cryptographic keys installed in a product during manufacture are
only used for the limited purpose of putting that device under
control of the user.
* Cryptographic keys and assertions related to management of devices
are only visible to the user they belong to and are never exposed
to external parties.
* Mesh Accounts belong to and are under control of the user they
belong to and not the Mesh Service provider which the user can
change at will with minimal inconvenience.
* Mesh Services do not have access to the plaintext of any Mesh
Messages or Mesh Catalog data except for the threshold catalog
used by the service as the source of access control policy.
* All Mesh Messages are subject to access control by both the
inbound and outbound Mesh Service to mitigate messaging abuse.
Hallam-Baker Expires 30 December 2023 [Page 9]
Internet-Draft Mesh Architecture 3.0 June 2023
Security is risk management and not the elimination of every possible
risk. Radical distrust means that we raise the bar for attackers to
the point where for most attackers the risk is greater than the
reward. It does not demand that we immediately address every issue
with perfection or delay deployment of technologies that are capable
of controlling _many_ risks until we have achieved the control of
_every_ risk.
In addition to distrusting technology providers the Mesh Architecture
allows the user to limit the degree of trust they place in
themselves. In the real world, devices are lost or stolen, passwords
and activation codes are forgotten, natural or man-made catastrophes
cause property and data to be lost. The Mesh permits but does not
require use of escrow techniques that allow recovery from such
situations.
3.1. The Device Management Challenge
Existing PKIs were developed in an era when the 'personal computer'
was still coming into being. Only a small number of people owned a
computer and an even smaller number owned more than one. In these
circumstances, it arguably sufficed to provision a user with a single
key pair on the single device they were likely to use. Creating keys
was a time-consuming business that might take several minutes, an
architecture in which an end user might create and use hundreds of
key pairs was beyond the capabilities of the available hardware.
Today, computers are ubiquitous and a typical home in the developed
world contains several hundred of which a dozen or more may have some
form of network access. The modern consumer faces a problem of
device management that is considerably more complex than the IT
administrator of a small business might have faced in the 1990s but
without any of the network management tools such an administrator
would expect to have available.
One important consequence of the proliferation of devices is that
end-to-end security is no longer sufficient. To be acceptable to
users, a system must be ends-to-ends secure. That is, a user must be
able to read their encrypted email message on their laptop, tablet,
phone, or watch with exactly the same ease of use as if the mail were
unencrypted. A cryptographic security control that impedes the user
is a control that is not going to be used.
Hallam-Baker Expires 30 December 2023 [Page 10]
Internet-Draft Mesh Architecture 3.0 June 2023
Each personal Mesh contains a device catalog in which the
cryptographic credentials and device specific application
configurations for each connected device are stored. A device
granted administration rights can use the device catalog to configure
each connected device with the precise cryptographic credentials it
needs to perform its functions.
3.2. Exchange of trusted credentials.
One of the most challenging, certainly the most contentious issues in
PKI is the means by which cryptographic credentials are published and
validated. Here there are two different challenges.
Developing an infrastructure that provides a mapping to a
cryptographic key from a name that serves no other purpose than
identifying the key is relatively easy. Developing an infrastructure
that maps existing names with semantics that are already established
is considerably harder.
The Mesh does not attempt to impose criteria for accepting
credentials as valid as no such set of criteria can be comprehensive.
Rather, the Mesh provides an internal trust infrastructure that makes
use of a _direct trust_ model similar to that of PGP fingerprints to
which external names may be mapped using whatever validation criteria
users consider are appropriate to the purpose for which they intend
to use them.
The principles of providing extended trust management in the Mesh are
further described in [draft-hallambaker-mesh-trust].
3.3. Application configuration management
Configuration of cryptographic applications is typically an
afterthought (or worse). Configuration of one popular mail user
agent to use S/MIME security requires 17 steps to be performed using
four separate application programs. And since S/MIME certificates
expire, the user is required to repeat these steps every few years.
Contrary to the public claims made by one major software vendor it is
not necessary to perform 'usability testing' to recognize abject
stupidity.
Rather than writing down configuration steps and giving them to the
user, we should turn them into code and give them to a machine.
Users should never be required to do the work of the machine. Nor
should any programmer be allowed to insult the user by casting their
effort aside and requiring it to be re-entered.
Hallam-Baker Expires 30 December 2023 [Page 11]
Internet-Draft Mesh Architecture 3.0 June 2023
While most computer professionals who are required to do such tasks
on a regular basis will create a tool for the purpose, most users do
not have that option. And of those who do write their own tools,
only a few have the time and the knowledge to do the job without
introducing security vulnerabilities.
3.4. Mesh Service Provider
As might be expected of a Key _Infrastructure_, use of the Mesh
typically requires the use of an online service to provide an always
present point of service through which devices which are not
permanently connected can exchange messages. This online service is
called a *Mesh Service Provider* (*MSP*).
An MSP performs similar functions to an SMTP mail provider but with
one important distinction: MSPs do not issue or own Mesh accounts. A
Mesh account is always created by and belongs to its user who can
change their MSP at any time without changing their account.
Further, a user MAY choose to act as their own MSP.
3.5. The Mesh as platform
Meeting the core objectives of the Mesh required new naming,
communication and cryptographic capabilities provided to be
developed. These capabilities may in turn be used to develop new
end-to-end secure applications.
For example, the Mesh Catalogs used to maintain collections of device
descriptions, bookmarks, credentials, etc. might be used in an
electronic records infrastructure to maintain chain of custody of
digital evidence.
3.6. Security
The Mesh is designed to provide the greatest practical level of
security that does not detract from the user experience. The usual
CIA triad is considered:
Confidentiality The confidentiality of user content should be
protected at all times and against all unauthorized parties
including their MSP.
Reasonable efforts should be taken to protect user data against
traffic analysis and metadata attacks. It is not necessary to
consider disclosure of this information to MSPs. Metadata must be
shielded from external parties but controls to prevent traffic
analysis may be left to implementers.
Hallam-Baker Expires 30 December 2023 [Page 12]
Internet-Draft Mesh Architecture 3.0 June 2023
Integrity The design should consider unauthorized modification of
data to be at least as serious as disclosure.
Availability The design should consider loss of data likely to be at
least as serious as disclosure.
In addition to protecting the user's data, the Mesh is designed to
protect the user's autonomy. While the use of any electronic device
or service entails a degree of trust, the user should have the right
to decide which devices and which service providers to trust and to
have the practical ability to revoke that trust at any time they
choose.
3.7. Enterprise Deployment
Development of PKI has traditionally focused on the needs of large
enterprises. The Mesh is focused on the individual user. While this
change of focus is in part a recognition of the need to reverse the
traditional bias, it is also a recognition of the fact that we must
understand the needs of the individual user before attempting to
understand the additional needs of an enterprise IT department
serving a large number of users.
4. User Experience
This section describes the Mesh in use. These _use cases_ described
here are re-visited in the companion Mesh Schema Reference
[draft-hallambaker-mesh-schema] and Mesh Protocol Reference
[draft-hallambaker-mesh-protocol] with further details and additional
examples.
For clarity and compactness of exposition, these use cases are
illustrated using the command line tool _meshman_, a tool that makes
the cryptographic operations explicit. This does not represent the
ideal user experience in which Zero-effort security is achieved.
Such a user experience requires that the Mesh operations be
seamlessly integrated into the user's applications so that instead of
using the meshman tool to encrypt or decrypt document, the word
processor application itself would be extended to read and write
documents encrypted in the DARE format.
4.1. Creating a Mesh Account
From the user's perspective, their personal Mesh consists of a
collection of devices that communicate seamlessly and securely
through a Mesh account serviced by an MSP.
Hallam-Baker Expires 30 December 2023 [Page 13]
Internet-Draft Mesh Architecture 3.0 June 2023
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 1: Alice's personal Mesh.
As with an email service provider, the user is only likely to be
aware of their interactions with their MSP in the case of a service
interruption. As far as the user is concerned the data is replicated
across their devices automatically unless there is a problem.
While the term 'account' is used because it is the term a user is
familiar with that most closely describes its functions, Mesh
accounts are different from traditional Internet accounts in one
important respect: In order to realize the principle of 'autonomy',
Mesh accounts are created by and _belong to_ the user and not the
service provider. Should a serious problem occur, a user may opt to
change their MSP. But unlike a changing an SMTP email provider, this
change is made seamless and cost free.
Another important difference between the Mesh and SMTP is that all
Mesh data is encrypted end to end. The MSP does not have access to
any user content and does not have access to any user meta-data
except that which is strictly necessary to service the account.
The only Mesh catalogs associated with a Mesh account that can be
read by an MSP are the Access Catalog which serves as the basis for
specifying and enforcing access control policy on the resources
associated with the account and the Publications Catalog which is an
index of encrypted data published through the account.
To create a Mesh account, the user need only specify the account name
and the initial MSP:
The user specifies the initial account address to be used
(alice@example.com). Use of this address is of course dependent on
authorization by the Mesh Service Provider (example.com) and is
likely to require authentication and possibly payment.
Alice> meshman account create alice@example.com
Account=alice@example.com
UDF=MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
The command returns the value of Alice's Mesh Account fingerprint .
This value is used as a unique identifier that is cryptographically
bound to the signature key used to authenticate the account profile.
Hallam-Baker Expires 30 December 2023 [Page 14]
Internet-Draft Mesh Architecture 3.0 June 2023
Note that the user does not specify the cryptographic algorithms to
use. Choice of cryptographic algorithm is primarily the concern of
the protocol designer, not the user. The only circumstance in which
users would normally be involved in algorithm selection is when there
is a transition in progress from one algorithm suite to another.
4.1.1. Encrypting and Decrypting files.
Having created an account, Alice can use it to encrypt files and
decrypt them on the same machine.
Alice encrypts the text file plaintext.txt to create an encrypted
version readable only by Alice:
Alice> meshman type plaintext.txt
This is a test
Alice> meshman dare encode plaintext.txt ciphertext.dare /encrypt ^
alice@example.com
Alice> meshman dare verify ciphertext.dare
File: ciphertext.dare
Bytes: 16
Encryption Algorithm: A256CBC
Recipient: MBUF-P7S2-WFEF-D3ML-OKCC-XYOT-6SLD
Digest Algorithm: S512
Payload Digest: 0F80F0A764D7A6F4AF97738E39FDD2ACD4F46D3FFEA567FFE
3DB2EE2A586E4D1F3D4158EEB6451FE39477A58ECADB8FA4FAC7D76FAA29AE811CC16
0E4F50B4AB
Alice can recover the file at any time using the decryption command:
Alice> meshman dare decode ciphertext.dare plaintext1.txt
Alice> meshman type plaintext1.txt
This is a test
Although the encrypted file can be accessed by Alice with precisely
the same ease as the plaintext version, the contents of the encrypted
file are not readable by any other user of the machine unless Alice
explicitly grants access. The encrypted file may be stored on a
shared drive, cloud file system or removable storage without
disclosing the contents.
While encrypting and decrypting files using a tool provides the
desired functionality, it does not meet our objectives for usability.
These capabilities should be integrated into applications or the
platform itself.
Hallam-Baker Expires 30 December 2023 [Page 15]
Internet-Draft Mesh Architecture 3.0 June 2023
4.1.2. Catalogs
Every Mesh account is created with a set of catalogs and spools. For
example, the bookmarks catalog maintains a list of the user's Web
bookmarks. The credentials catalog maintains a list of the user's
usernames and passwords for the various network services they use.
As with the file encryption example, these capabilities are clearly
going to be most effective when incorporated into the user's
applications, (i.e. their Web browser).
Alice adds the username and password she uses to access her weather
service account to her credentials catalog:
Alice> meshman password add ftp.example.com alice1 password
alice1@ftp.example.com = [password]
Alice> meshman password add www.example.com alice@example.com ^
newpassword
alice@example.com@www.example.com = [newpassword]
As with all Mesh Catalogs, the catalog data is encrypted and cannot
be accessed by any unauthorized party including the Mesh Service
Provider.
If needed, she can retrieve the credentials from the catalog by
specifying the network resource to which access is required:
Alice> meshman password get ftp.example.com
alice1@ftp.example.com = [password]
This capability provides a means of preventing one of the most common
causes of enterprise password breach in which a system administrator
encodes the access credentials for a service into a script used to
access the service. A script containing a command to extract the
credentials from a Mesh catalog will only work for a user authorized
to access the credentials in the Mesh.
4.2. Adding devices
Computers have become ubiquitous and inexpensive. Most people living
in affluent countries interact with several dozen computer systems
every day. Every household appliance from the television to the
coffee pot has become or is in the process of becoming a computer.
It is this circumstance that has exposed the critical flaw in
traditional PKI: The lack of practical means of managing private keys
across multiple devices.
Hallam-Baker Expires 30 December 2023 [Page 16]
Internet-Draft Mesh Architecture 3.0 June 2023
The Mesh allows users to connect all their devices together so that
they may be considered part of a single entity whose component parts
communicate and interact seamlessly and securely.
Although any type of network capable device may be connected to a
Mesh profile, some devices are better suited for use with certain
applications than others. Connecting an oven to a Mesh profile could
allow it to be controlled through entries to the user's recipe and
calendar catalogs and alert the user when the meal is ready but
attempting to use it to read emails or manage Mesh profiles. The
Mesh allows the principle of least privilege when connecting a device
granting precisely the set of capabilities required to perform its
intended function.
Multiple connection mechanisms are specified, each of which provides
strong mutual authentication. In each case, the connection request
must be approved by a device provisioned with the Mesh administration
privilege:
Direct The connection request is initiated on the device being
requested and approved on the administration device.
Authentication of the connection request is performed by comparing
witness values presented on the connecting device and the
administration device.
PIN A PIN code is generated on an administration device and passed
to the connecting device out of band. The connecting device
provides proof of knowledge of this PIN code when making the
connection request allowing an administration device to approve
the request automatically without further user interaction.
Dynamic QR This connection mechanism is a variation of the PIN
connection mechanism in which administration device presents the
PIN code value to the connecting device in the form of a QR code.
This allows a connecting device with a camera to connect with
minimal user effort.
Static QR This connection method is designed to support connection
of constrained IoT devices that lack a camera or display
capability but requires that the device be pre-provisioned during
manufacture or distribution.
An administration device equipped with a camera reads a static QR
code printed on the device that provides the information used to
enable the administration device to establish a local network
connection (e.g. WiFi, Bluetooth, strobe, IR) that can be used to
complete the connection.
Hallam-Baker Expires 30 December 2023 [Page 17]
Internet-Draft Mesh Architecture 3.0 June 2023
These connection mechanisms are described in detail in the Mesh
Protocol Reference [draft-hallambaker-mesh-protocol].
4.2.1. Direct Connection
For example, Alice connects a second device using the direct
connection mechanism:
The connection request is initiated on the device being connected:
Alice2> meshman device request alice@example.com
Device UDF = MBYI-QYCM-JXEY-OJ5D-4OW2-RPIR-SHUM
Witness value = Z3PE-JMM5-G3XQ-CB3Q-LNX4-2YY6-Q74Y
Using her administration device, Alice gets a list of pending
requests. Seeing that there is a pending request matching the
witness value presented by the device, Alice accepts the request,
granting the new device the messaging and web roles:
Alice> meshman device pending
MessageID: Z3PE-JMM5-G3XQ-CB3Q-LNX4-2YY6-Q74Y
Connection Request::
MessageID: Z3PE-JMM5-G3XQ-CB3Q-LNX4-2YY6-Q74Y
To: From:
Device: MBYI-QYCM-JXEY-OJ5D-4OW2-RPIR-SHUM
Witness: Z3PE-JMM5-G3XQ-CB3Q-LNX4-2YY6-Q74Y
Alice> meshman device accept Z3PE-JMM5-G3XQ-CB3Q-LNX4-2YY6-Q74Y ^
/message /web
Alice can now synchronize her newly connected device to her account:
Alice2> meshman device complete
Device UDF = MBYI-QYCM-JXEY-OJ5D-4OW2-RPIR-SHUM
Account = alice@example.com
Account UDF = MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
4.2.2. PIN Connection
Alice connects a third device using the PIN code connection
mechanism:
The Alice begins the connection process by creating a one time use
PIN authentication code on her administration device. The PIN
creation request specifies the rights to be granted to the connecting
device:
Hallam-Baker Expires 30 December 2023 [Page 18]
Internet-Draft Mesh Architecture 3.0 June 2023
Alice> meshman account pin /threshold
PIN=AAKI-IIAD-GQ3H-JUY3-SXZN-PENW-PQ
(Expires=2023-06-29T17:00:45Z)
A connection request is made on the connecting device as before
except that this time the PIN is specified. This time, only the
'threshold' right is granted.
Alice3> meshman device request alice@example.com /pin ^
AAKI-IIAD-GQ3H-JUY3-SXZN-PENW-PQ
Device UDF = MBXV-SIBF-4XEW-4EVE-7URW-F6VT-NTX3
Witness value = GSJR-OHU5-HHXO-KURY-ST4B-HVBA-7PV5
Since the connection request is pre-authenticated by the PIN, it is
not necessary for Alice to review the connection request. The
connection request is accepted automatically when the administration
device is synchronized:
Alice> meshman message pending
MessageID: GSJR-OHU5-HHXO-KURY-ST4B-HVBA-7PV5
Connection Request::
MessageID: GSJR-OHU5-HHXO-KURY-ST4B-HVBA-7PV5
To: From:
Device: MBXV-SIBF-4XEW-4EVE-7URW-F6VT-NTX3
Witness: GSJR-OHU5-HHXO-KURY-ST4B-HVBA-7PV5
MessageID: NCUD-3ROZ-X7UK-MMRA-CTYI-YHOE-UJCM
MessageID: NDTU-IIPR-L5SK-L6CZ-JJGF-XA6L-565H
Confirmation Request::
MessageID: NDTU-IIPR-L5SK-L6CZ-JJGF-XA6L-565H
To: alice@example.com From: console@example.com
Text: start
MessageID: ND4Y-TGCW-2QO3-KIQM-N3AN-DMIO-2CFT
MessageID: NCVI-FDFU-ZYPN-5274-YBHY-V6WI-FTEJ
MessageID: NA7V-2XT2-2ZJO-IDUY-GK6W-CTVX-HDDM
Alice> meshman account sync /auto
Alice can now synchronize her newly connected device to her account:
Alice3> meshman device complete
Device UDF = MBXV-SIBF-4XEW-4EVE-7URW-F6VT-NTX3
Account = alice@example.com
Account UDF = MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
Alice3> meshman account sync
The Dynamic QRCode connection scheme uses exactly the same mechanism
except that instead of the PIN being presented to Alice in the form
of an alphanumeric string, the connection information is encoded as a
URI and presented to the connecting device as a QR code.
Hallam-Baker Expires 30 December 2023 [Page 19]
Internet-Draft Mesh Architecture 3.0 June 2023
The URI corresponding to the connection PIN is:
mcu://alice@example.com/AAKI-IIAD-GQ3H-JUY3-SXZN-PENW-PQ
4.2.3. Making use of the new device
Having connected a second device and granted it web access rights,
Alice can use it to decrypt files and access her bookmark and
password catalogs in exactly the same fashion as the first. If a
password is changed on one device, all her connected devices receive
the update.
For example, because Alice granted the device the Web role, she can
now access her credential catalog and decrypt the file she encrypted
on her first device from the new device:
Alice2> meshman password get ftp.example.com
alice1@ftp.example.com = [password]
Alice2> meshman dare decode ciphertext.dare plaintext2.txt
Alice2> meshman type plaintext2.txt
This is a test
By default, devices connected with the web access right can access
all the catalogs connected to a personal Mesh. Devices MAY be
connected with greater or lesser access rights according to their
intended use. A coffee pot does not require access to the password
catalog or the ability to send messages to other Mesh users. A
software development station is likely to require the ability to sign
commits to a source code repository.
Limiting the access rights granted to a device when it is connected
mitigates the consequences of the device being lost, stolen or
infected by malware before the compromise occurs. Disconnecting the
device from the user's personal Mesh as described in a later section
provides further mitigation.
4.2.4. Applications
Connected devices can also make use of connected applications for
which they are granted the necessary rights.
Alice creates an SSH profile within her Mesh on the administrative
device making the private key information available to devices she
has connected to her Mesh with the 'web' access right.
Alice> meshman ssh create /web /threshold /id=ssh
UDF: MAOY-3KTL-BIW6-BS7V-EANA-AZTL-5Q2Y
Hallam-Baker Expires 30 December 2023 [Page 20]
Internet-Draft Mesh Architecture 3.0 June 2023
She can extract the private key to configure her SSH clients:
Alice> meshman ssh get ssh /private /file=alice1_ssh_prv.pem
She can also extract her public key to configure her SSH server to
allow access to the machine:
Alice> meshman ssh get ssh /file=alice1_ssh_pub.pem
Ideally these steps would be performed on Alice's behalf by an
automated script that detects the applications Alice has installed on
her device and performs the necessary configuration on her behalf.
The SSH keys created on one device are available to every device
connected by the 'web' access right:
Alice2> meshman account sync
Alice2> meshman ssh get ssh /private /file=alice2_ssh_prv.pem
At present the Mesh only supports an SSH configuration in which a
single client key is shared across multiple devices. The Mesh is in
principle capable of supporting more sophisticated configurations in
which each device has its own individual client key. Consideration
of these configuration modes is currently outside the scope of work
for the Mesh and is probably more usefully considered as part of an
effort to integrate Mesh functionality into the SSH system. Such an
effort would also describe the means by which SHH server key
fingerprints are recorded in the Mesh Contacts catalog.
Support for SMTP mail with OpenPGP and S/MIME end to end security is
supported in a similar fashion.
4.2.5. Threshold Key Devices
As is to be expected of a Threshold Key Infrastructure, Mesh devices
MAY be configured to use a threshold key share for decryption, the
other key share being held by the Mesh service servicing the account.
Connecting a device with the threshold access right grants it the
same range of functionality as the web access right for as long as it
is connected to the user's personal Mesh. Instead of being
provisioned with the account decryption key, the device is
provisioned with a key share. To decrypt documents encrypted to the
account key, the device requires the active participation of the
service holding the other half of the shared key. This allows the
service to prevent further use of the decryption capability by the
device after it has been disconnected from that personal Mesh.
Hallam-Baker Expires 30 December 2023 [Page 21]
Internet-Draft Mesh Architecture 3.0 June 2023
Provisioning devices with threshold access rights has the advantage
of allowing greater control of the decryption capability at the cost
of requiring an interaction with the network service for each
decryption operation. There is thus a tradeoff between performance
and security.
While the Mesh architecture permits any decryption key to be
threshold shared, it is RECOMMENDED that implementations use this
capability sparingly and develop mechanisms that avoid the need for a
device to preform repeated threshold operations to decrypt the same
data. For example, rather than decrypting every entry in the
password catalog each time it is used, a device should encrypt a
primary secret under the account threshold key that can be decrypted
each time the device is activated and re-encrypt threshold encrypted
data to that secret each time a threshold decryption is performed.
This provides the same security properties with considerably less
load on the service.
The current version of the Mesh protocols require that the
administration device used to provision threshold keys to a device
have access to the original key. As described in
[draft-hallambaker-mesh-schema], this requirement will be lifted in a
future edition of the protocol.
4.3. Mesh Messaging
The Mesh Messaging system is a push messaging system analogous to
SMTP, but its purpose is limited to secure exchange of control plane
messages. This leads to some important differences:
* Every message is signed and end-to-end encrypted
* The only communication pattern supported is a four-corner model in
which users exchange messages through their respective MSPs.
* Every message is subject to access control at the inbound and
outbound MSP.
* Message content is limited to 32KB.
Hallam-Baker Expires 30 December 2023 [Page 22]
Internet-Draft Mesh Architecture 3.0 June 2023
This size restriction ensures that exchange of Mesh Messages does not
impose an undue burden on the inbound and outbound MSP. While users
can and do send much larger messages, 32KB should be more than
sufficient to demonstrate to the recipient that the message should be
accepted. It is not necessary for a sender to transfer multiple MB
message before the receiver decides to refuse it. Connected devices
may efficiently synchronize their message spools even over limited
bandwidth connections. A short message is never blocked by a larger
one.
For exchange of longer messages, a pull model is employed. A short
Mesh message sent a message advising the recipient's client of the
location from which the full content may be obtained. This approach
has many benefits over the SMTP push model. There is no longer a
need for any limitation on message size. The same messaging platform
can be used to send a short text message, a spreadsheet or raw video
file archives spanning multiple TB.
Exchange of certain content types naturally leads to security
concerns. These concerns are mitigated in the Mesh by performing
access control on every message. When accepting Bob as a partner,
Alice can choose the types of Mesh Message and the types of content
she is willing to accept from him. Thus, Alice might be willing to
accept a spreadsheet containing macro code from Bob but not from
Carol or Mallet. And she might not want to accept anything at all
from Susan because of past abuse.
While there are important technical differences between Mesh
Messaging and SMTP, these are not visible to Alice or Bob except
insofar as there is no restriction on message size other than the
storage capacity of the machine they wish to receive the messages on,
there is very little scope for messaging abuse and (unless the Mesh
becomes ubiquitous) they can only use Mesh Messaging to communicate
with other Mesh users. Thus, while Mesh messaging has been designed
to enable replacement of SMTP in the long term, it is not currently a
focus for the client implementations. Use of Mesh messaging is thus
currently limited to support for applications built on the Mesh
platform. One of those applications is the device connection
protocol describe earlier. Another is the contact exchange protocol
used to acquire contact information from other Mesh users.
4.3.1. Contact exchange
Besides management of private keys across devices, the biggest
obstacle to effective use of existing security protocols such as SSH,
OpenPGP and S/MIME is the difficulty of obtaining the authentic
public keys of the counterparties.
Hallam-Baker Expires 30 December 2023 [Page 23]
Internet-Draft Mesh Architecture 3.0 June 2023
The question of issue and validation of credentials is a complex and
difficult one that does not have a single answer that is valid for
every use case. For certain applications credentials issued by a
Trusted Third Party are appropriate. For others, the Web of Trust
proposed in OpenPGP provides a better fit to the requirements and
constraints. These issues are discussed in
[draft-hallambaker-mesh-trust].
Rather than imposing a single trust model for credential acquisition,
the Mesh allows the use of whatever model is best for validating a
credential for a particular use. It is unlikely Alice would have the
same security concerns for communication with her employer, her
friends, her bank, etc.
For many applications, Trust After First Use provides an adequate
basis for credential acquisition.
Alice wants to exchange Mesh messages with Bob. Although Alice knows
Bob's Mesh address (bob@example.com), she does not (yet) have
permission to send any message to Bob excepting a request to exchange
contact information.
Bob sends Alice a contact exchange request:
Bob> meshman contact request alice@example.com
Envelope ID: MAE2-VMU3-PDAH-HZX7-CGYV-75XQ-Z4EA
Message ID: NAQL-6SJP-VLQD-7BNN-EB6L-DLQQ-K2ZE
Response ID: MDNG-ME2U-6X4T-FEVR-46MH-2RLM-WCOP
Alice checks his Mesh messages and approves Bob's request:
Hallam-Baker Expires 30 December 2023 [Page 24]
Internet-Draft Mesh Architecture 3.0 June 2023
Alice> meshman account sync
Alice> meshman message pending
MessageID: ND2G-PHUE-PLPY-QAPP-UU6P-BAXW-EOBS
Contact Request::
MessageID: ND2G-PHUE-PLPY-QAPP-UU6P-BAXW-EOBS
To: alice@example.com From: mallet@example.com
PIN: ACGN-LZXP-H2WB-R5UE-VGMF-VGQD-AR5Q
MessageID: NAQL-6SJP-VLQD-7BNN-EB6L-DLQQ-K2ZE
Contact Request::
MessageID: NAQL-6SJP-VLQD-7BNN-EB6L-DLQQ-K2ZE
To: alice@example.com From: bob@example.com
PIN: AAAZ-RZSW-ZMBI-A6R6-WTPY-INAA-OZLQ
MessageID: NA7V-2XT2-2ZJO-IDUY-GK6W-CTVX-HDDM
Alice> meshman message accept NAQL-6SJP-VLQD-7BNN-EB6L-DLQQ-K2ZE
Alice> meshman contact list
Entry: MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
Person MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
Anchor MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
Address alice@example.com
Entry: NCIO-3ZRE-NYUC-XRNS-CDLI-HL42-EDBR
Person
Anchor MDCR-A2UE-SKQA-3HBF-YFO6-VQ6H-E72X
Address bob@example.com
Bob can now collect Alice's contact:
Bob> meshman account sync /auto
Bob> meshman contact list
Entry: MDCR-A2UE-SKQA-3HBF-YFO6-VQ6H-E72X
Person MDCR-A2UE-SKQA-3HBF-YFO6-VQ6H-E72X
Anchor MDCR-A2UE-SKQA-3HBF-YFO6-VQ6H-E72X
Address bob@example.com
Entry: ND4G-SEV3-KQ5B-U4F4-YXHC-JUVK-EO73
Person
Anchor MB3T-WIPZ-JRCW-QZFM-SCQL-OVVO-AHO2
Address alice@example.com
At this point Alice and Bob can exchange Mesh messages of any type
with seamless end to end security. Every Mesh message is signed and
encrypted without exception. If Alice and Bob have used the Mesh to
configure their email accounts for OpenPGP or S/MIME, they can use
these to exchange end-to-end secure SMTP mail.
Alternatively, Bob might have opted to grant Alice only specific
messaging access. Bob might choose to restrict synchronous messaging
modalities such as instant messaging or voice that interrupt his
Hallam-Baker Expires 30 December 2023 [Page 25]
Internet-Draft Mesh Architecture 3.0 June 2023
workflow to specific colleagues. The fact that Alice wants to speak
to Bob does not necessarily mean she is interested in what he might
say in reply. Thus, messaging access need not be reciprocated.
As with device connection, multiple contact exchange methods are
supported including the use of a QR code printed on a business card
or presented on a mobile device. These methods are also described in
[draft-hallambaker-mesh-protocol].
As a respected figure within the cryptographic community, Alice might
employ a curation service for credential requests advising her that
Bob's credentials appear to be in order while Mallet's are
suspicious. Such services might be offered by her MSP or another
provider. Alice might be willing to accept contact requests from
members of professional associations she is a member of or who have
attended certain conferences in her field. A variety of approaches
might be followed for curation of other requests including Machine
Learning approaches.
4.3.2. Confirmation service
The Mesh confirmation service is an improvement of traditional second
factor authentication techniques offering offers far greater
usability and security.
Instead of being asked to present a meaningless numeric code, Alice
is presented a request from a named, authenticated source to confirm
a specific action. Alice's response will be signed using a signature
key that is unique to the particular confirmation device she uses,
thus providing a non-repudiable record of her decision.
Alice attempts to log into a secure console in the control room. The
secure console recognizes Alice but a second factor is required. The
console issues a challenge to Alice at her registered account asking
if she would like to log into the secure console:
Console> meshman message confirm alice@example.com start
Envelope ID: MBRF-HV6Z-UAXU-IUP5-4B6A-XIRE-UHGZ
Message ID: NDTU-IIPR-L5SK-L6CZ-JJGF-XA6L-565H
Response ID: MB7S-ZUPK-XJ6Q-N42Y-4UTW-7CQI-33HL
Alice checks her pending messages and accepts the request:
Alice> meshman message accept NDTU-IIPR-L5SK-L6CZ-JJGF-XA6L-565H
The secure console verifies the response and grants access:
Hallam-Baker Expires 30 December 2023 [Page 26]
Internet-Draft Mesh Architecture 3.0 June 2023
Console> meshman message status MB7S-ZUPK-XJ6Q-N42Y-4UTW-7CQI-33HL
Accept
In an enterprise environment, tying the confirmation process to a
specific source, a specific action and specific device allows for
confirmation interactions to be used to implement business processes
with attribution and thus accountability.
Using traditional second factor approaches, a system administrator
presents their credentials to authenticate access to the machine at
which point they can perform any action permitted by their current
privileges. This typically includes modification of any access logs
that might be kept. Using the confirmation approach the individual
actions of the system administrator may be authenticated, traced and
logged. If a user account is added to the system, it is known which
administrator is responsible and the device that was used. This
information may then be used if it becomes necessary to unwind the
consequences of a breach or an insider threat.
4.4. Encryption Groups
As seen earlier, the Mesh allows encrypted files to be shared with
other named users. While this capability is sufficient for simple
messaging type use cases, decades of experience prove that it is
inadequate to meet the needs of protecting data at rest. In the
simple messaging case the list of recipients is known to the sender
at the time a message is sent. In the general case the party
encrypting the data cannot know the list of intended readers because
that will change over time.
Even in the smallest organization, employees join and leave. A new
employee must be granted access to all the information they need for
their work. The access rights of a terminated employee must also
terminate.
Traditional 'Digital Rights Management' product employ key management
techniques originating in the field of copyright enforcement to
control access to content by controlling disclosure of symmetric
decryption keys. This provides the necessary flexibility to control
access to the data but leaves the decryption keys vulnerable to a
server breach. Such systems do not provide 'end-to-end' security in
any useful sense.
Use of threshold techniques allows a threshold service to control
decryption of the data without having the ability to decrypt.
Sharing data through a Mesh group allows access to be controlled
without loss of end-to-end encryption.
Hallam-Baker Expires 30 December 2023 [Page 27]
Internet-Draft Mesh Architecture 3.0 June 2023
Alice creates the recryption group groupw@example.com to share
confidential information with her closest friends:
Alice> meshman group create groupw@example.com /web
Account=groupw@example.com
UDF=MBXT-N7ZN-3U5H-HTTC-4VWF-6WA5-LKGR
Alice encrypts a test file but she can't decrypt it because she
hasn't added herself to the group yet.
Alice> meshman type grouptext.txt
The group secret handshake
Alice> meshman dare encode grouptext.txt groupsecret.dare /encrypt ^
groupw@example.com
Alice> meshman dare decode groupsecret.dare grouptext_alice.dare
ERROR - No decryption key is available
Alice adds herself to the group, now she can decrypt:
Alice> meshman group add groupw@example.com alice@example.com
alice@example.com [MBC4-37NG-TMFD-MWQO-K7RD-3M4V-FSN2]
Alice> meshman account sync /auto
Alice> meshman dare decode groupsecret.dare grouptext_alice.dare
Alice> meshman type grouptext_alice.dare
The group secret handshake
At this point, Bob can't encrypt or decrypt messages because he
doesn't know the public key and he isn't in the group. Alice could
allow Bob to encrypt but not decrypt by sending him the group contact
information without a decryption share. Instead she adds Bob to the
group as a member:
Alice> meshman group add groupw@example.com bob@example.com
bob@example.com [MBC4-37NG-TMFD-MWQO-K7RD-3M4V-FSN2]
Adding Bob to the group gives him immediate access to any file
encrypted under the group key without making any change to the
encrypted files:
Bob> meshman account sync /auto
Bob> meshman dare decode groupsecret.dare grouptext_bob.dare
Bob> meshman type grouptext_bob.dare
The group secret handshake
Removing Bob from the group immediately withdraws his access.
Hallam-Baker Expires 30 December 2023 [Page 28]
Internet-Draft Mesh Architecture 3.0 June 2023
Alice> meshman group delete groupw@example.com bob@example.com
bob@example.com [MBC4-37NG-TMFD-MWQO-K7RD-3M4V-FSN2]
Bob cannot decrypt files encrypted under the group key any more. But
he still has access to the file grouptext_bob.dare he decrypted
earlier.
Bob> meshman dare decode groupsecret.dare grouptext_bob2.dare
ERROR - A cryptographic operation was refused.
Bob> meshman type grouptext_bob.dare
The group secret handshake
The threshold key service acts as a policy enforcement point and can
impose additional accounting and authorization controls on the use of
the decryption service.
For example, the threshold key service might be configured to alert a
supervisor and/or deny decryption requests if a group member made an
unusual volume of requests in a short period.
4.5. Deleting Devices
If a connected device is lost, stolen or simply broken, Alice can
limit further use of the device by disconnecting it from her Mesh:
Alice disconnects the new device:
Alice> meshman device delete MBYI-QYCM-JXEY-OJ5D-4OW2-RPIR-SHUM
ERROR - Cannot access a closed file.
Disconnecting a device will always prevent the device receiving
further services from the account service and thus the ability to
receive encrypted catalog updates. But a device connected with
direct key access rights (e.g. web) is still capable of decrypting
documents encrypted under the account key unless the device
application discovers that it has been disconnected and deletes the
corresponding keys:
The device can no longer access the password catalog, but it can
still decrypt files:
Alice2> meshman account sync
ERROR - The server returned an invalid response.
Alice2> meshman dare decode ciphertext.dare plaintext3.txt
Alice2> meshman type plaintext3.txt
This is a test
Hallam-Baker Expires 30 December 2023 [Page 29]
Internet-Draft Mesh Architecture 3.0 June 2023
A device connected with the threshold access right loses the ability
to decrypt immediately:
The third device was connected with threshold rights, it is
disconnected in the same way as before.
Alice> meshman device delete MBXV-SIBF-4XEW-4EVE-7URW-F6VT-NTX3
ERROR - Cannot access a closed file.
The device can no longer access the password catalog or decrypt
files:
Alice3> meshman account sync
ERROR - The server returned an invalid response.
Alice3> meshman dare decode ciphertext.dare plaintext3.txt
ERROR - A cryptographic operation was refused.
4.6. Escrow and Recovery
While disclosure of sensitive data might cause serious harm to its
owner it is very rarely the case that the consequences of disclosure
are greater than the consequences of loss. Thus, whenever static
data is to be encrypted, the question of key recovery must be
considered.
Alice decides to create a recovery key set. To do this, she
specifies the number of key shares to be created and the number
required for recovery:
Alice> meshman account escrow
Share: SAQK-7F3L-IRHQ-IFYI-T63W-V6NA-TDZO-GCIT-RMEE-SC5P-2MB5-CF5P-FG
PR-IYCC-JJMQ
Share: SAQZ-OLOU-FUHQ-V624-U2KC-43V2-RHX2-WOLY-4VLM-4YDL-LKPE-56WU-DO
WU-NHHB-7SDQ
Share: SARH-5RB5-CXHR-DX5Q-VVYP-DY6U-PLWH-G2O6-H6SV-HNJG-4I4M-ZXPZ-BW
5X-RWMB-V22Q
Recovery of the key data requires the key recovery record and a
quorum of the key shares:
>>>> Unfinished ArchitectureRecovery
Alice2> meshman account recover /verify
ERROR - No account specified
Hallam-Baker Expires 30 December 2023 [Page 30]
Internet-Draft Mesh Architecture 3.0 June 2023
4.7. Future Directions
The Mesh is a Threshold Key Infrastructure and as with any
infrastructure, it is designed as a platform to support as wide a
range of future developments as possible. Selection of the initial
feature set was determined by the need to achieve zero-effort
security.
Further development of the Mesh will require careful consideration of
costs and benefits. The range of security features that could be
added is infinite, the range of features that should be added is
small. Real world deployment and use is required before extensive
addition of new features.
4.7.1. Device Disconnection
While 'single sign on' gets much attention in the Enterprise
computing space, it is actually 'single sign off' that provides the
real security value. Future enhancements of the Mesh will consider:
?A notification mechanism to allow a disconnected device to advise
the user that it has completely disconnected from the user's Mesh and
deleted relevant data.
?Use of trustworthy hardware to prevent use of confidential data
accessed through a personal Mesh after the device is disconnected.
?Use of threshold timed key release to limit the period during which
a device has access to confidential data.
4.7.2. Service Transition
Allowing users to transfer their accounts from one service provider
to another without switching costs is an important goal of the Mesh
project. Enabling such transfers is the principal purpose of the
Callsign registry [draft-hallambaker-mesh-callsign].
Support for account transition is currently limited and untested. In
theory a user MAY transfer their account from one service provider to
another by opening an account at the new service provider and
uploading the data provided that they have access to the profile
primary secret and all threshold key shares granted to the devices
are regenerated.
A different application of threshold cryptography and in particular
the use of threshold techniques to generate key shares would allow a
user to transfer their account without the need to reconstitute the
primary secret.
Hallam-Baker Expires 30 December 2023 [Page 31]
Internet-Draft Mesh Architecture 3.0 June 2023
4.7.3. Threshold User Account
At present the administration device has direct access to the
administrator key and it is not possible to determine which device
performed a particular administration action. Similarly, the
administration device requires access to the full decryption keys to
create threshold key shares for devices.
As with the service transition issue described earlier, meeting this
particular requirement using threshold cryptography is
straightforward in itself. The challenge lies in meeting the
requirements simultaneously. Or to be more precise, the challenge
lies in understanding what the precise requirements are.
A sketch has been developed of an approach addressing both sets of
requirements as currently understood. Instead of using an additive
key splitting approach for creating key shares, the additive approach
is combined with a Shamir/Lagrange approach such that:
* A single administration device can connect devices using key
shares mediated by the current service.
* Two administration devices can create the necessary signatures and
key shares to transfer the account to a different service
provider.
* Two administration devices can add a third administration device
with the same capabilities as the original two.
Achieving the last requirement makes use of the fact that Lagrange
interpolation can be used to generate additional shares without
reconstructing the original secret. The x coordinate of each share
holder is determined from the fingerprint of the device profile
signature key.
4.7.4. Threshold Group Administration
The current group encryption architecture requires that the group
administrator have access to the decryption key. The administrator
is thus able to decrypt any documents they chose and bypass the
accounting restrictions of the service.
Further application of threshold techniques would allow the
administrator role to be split between two or more parties, one of
which might be a service enforcing additional controls.
Hallam-Baker Expires 30 December 2023 [Page 32]
Internet-Draft Mesh Architecture 3.0 June 2023
4.7.5. Synchronous Messaging
Addition of a presence service capability to the MSP would allow Mesh
Messaging to be used to support the full range of synchronous
messaging services from text chat (e.g. xmpp) to video and VOIP. The
chief security benefit to the end user for such a scheme would be
that every communication request is mediated by access control.
While it is impossible to absolutely guarantee that every possible
form of abuse is prevented, stopping the organized crime ring that
just called me purporting to be my credit card company is much more
straightforward.
The main technical issue to be addressed to enable such a service is
specifying a means of layering Mesh Messages direct over UDP
transport. This is currently at the concept phase. While the
precise means of layering audio and video formats onto a network
connection is a complex problem, it is one that has already been
solved by existing standards.
4.7.6. Social Media
One of the chief distinctions between messaging and 'social media'
and is that the former is typically used to describe a synchronous
interaction between a closed group of users while most social media
consists of asynchronous interactions which are frequently (but not
always) public.
The Data At Rest Envelope technology used in the Mesh was originally
designed to support asynchronous social media interactions with full
end-to-end confidentiality. The service hosting a forum or
discussion board need not have access to the content of the messages
to support the complete range of user interactions.
5. Mesh Cryptography
All the cryptographic algorithms used in the Mesh are either industry
standards or present a work factor that is provably equivalent to an
industry standard approach. Since threshold cryptography is not
currently part of the 'canon' from which designers of cryptographic
security protocols work, much of the cryptography used in the Mesh
has been designed for the Mesh. Despite this fact, it is properly
regarded as part of the Internet platform on which the Mesh is built
rather than a part of the Mesh itself.
Hallam-Baker Expires 30 December 2023 [Page 33]
Internet-Draft Mesh Architecture 3.0 June 2023
Existing Internet security protocols are based on approaches
developed in the 1990s when performance tradeoffs were a prime
consideration in the design of cryptographic protocols. Security was
focused on the transport layer as it provided the best security
possible given the available resources.
With rare exceptions, most computing devices manufactured in the past
ten years offer either considerably more computing power than was
typical of 1990s era Internet connected machines or considerably
less. The Mesh architecture is designed to provide security
infrastructure both classes of machine but with the important
constraint that the less capable 'constrained' devices are considered
to be 'network capable' rather than 'Internet capable' and that the
majority of Mesh related processing will be offloaded to another
device.
For example, Alice uses her Desktop and Laptop to exchange end-to-end
secure Mesh Messages and documents but her Internet-of-Things food
blender and light bulb are limited in the range of functions they
support and the telemetry information they provide. The IoT devices
connect to a Mesh Hub which acts as an always-on point of presence
for the device state and allows complex cryptographic operations to
be offloaded if necessary.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 2: Constrained Devices connected through a Mesh Hub.
5.1. Best Practice by Default
Except where support for external applications demand otherwise, the
Mesh requires that the following 'best practices' be followed:
Industry Standard Algorithms All cryptographic protocols make use of
the most recently adopted industry standard algorithms.
Strongest Work Factor Only the strongest modes of each cipher
algorithm are used. All symmetric encryption is performed with
256-bit session keys and all digest algorithms are used in 512-bit
output length mode.
Key Hygiene Separate public key pairs are used for all cryptographic
functions: Encryption, Signature and Authentication. This enables
separate control regimes for the separate functions and
partitioning of cryptographic functions within the application
itself.
Hallam-Baker Expires 30 December 2023 [Page 34]
Internet-Draft Mesh Architecture 3.0 June 2023
Bound Device Keys Each device has a separate set of Encryption,
Signature and Authentication key pairs. These MAY be bound to the
device to which they are assigned using hardware or other
techniques to prevent or discourage export.
No Optional Extras Traditional approaches to security have treated
many functions as being 'advanced' and thus suited for use by only
the most sophisticated users. The Mesh rejects this approach
noting that all users operate in precisely the same environment
facing precisely the same threats.
Industry best practices change over time. In the 1990s it was
generally believed that supporting the widest possible range of
cryptographic algorithms allowed the greatest highest level of
security. This view has been decisively rejected in the light of the
objection that a successful downgrade attack results in the security
afforded by the weakest algorithm supported.
5.2. Multi-Level Security
All Mesh protocol transactions are protected at the Transport,
Message and Data level. This provides security in depth that cannot
be achieved by applying security at the separate levels
independently. Data level encryption provides end-to-end
confidentiality and non-repudiation, Message level authentication
provides the basis for access control and Transport level encryption
provides a degree of protection against traffic analysis.
5.3. Threshold Decryption
Traditional public key encryption algorithms have two keys, one for
encryption and another for decryption. The Mesh makes use of
threshold cryptography techniques to allow the decryption key to be
split into two or more parts.
For example, if we have a private key _z_, we can use this to perform
a key agreement with a public key _S_ to obtain the key agreement
value A. But if _z_ = (_x+y_) mod _g_ (where g is the order of the
group). we can obtain the exact same result by applying the private
keys _x_ and _y_ to _S_ separately and combining the results:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 3: Two key decryption.
Hallam-Baker Expires 30 December 2023 [Page 35]
Internet-Draft Mesh Architecture 3.0 June 2023
The approach to threshold decryption used in the Mesh was originally
inspired by the work of Matt Blaze et. al. on proxy re-encryption.
But the approach used may also be considered a form of Torben
Pedersen's Distributed Key generation which is in turn one form of
threshold cryptography.
This technique is used in the Mesh to allow use of decryption key
held by a user to be controlled by a cloud service without giving the
cloud service the ability to decrypt by itself.
These techniques are described in detail in
[draft-hallambaker-threshold].
5.4. Threshold Key Generation
The mathematics that support threshold decryption are also the basis
for the multi-party key generation mechanism that is applied at
multiple levels in the Mesh. The basis for the multi-party key
generation used in the Mesh is that for any Diffie-Hellman type
cryptographic scheme, given two keypairs { _x_, _X_ }, { _y_, _Y_ },
we calculate the public key corresponding to the private key _x_+ _y_
using just the public key values _X_and _Y_.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 4: Two party key pair generation.
Threshold key generation ensures that keys used to bind devices to a
personal Mesh or within a Mesh account are 'safe' if any of the
contributions to the generation process are safe.
These techniques are also described in detail in
[draft-hallambaker-threshold].
5.5. Threshold Signature
The techniques that support threshold decryption and key generation
are also applicable to signature albeit with some very important
constraints. Incorrect implementation of the techniques used to
create ECDSA signatures can result in disclosure of the private key.
It is therefore essential that a threshold signature algorithm is
rigorously reviewed.
This technique is used in the mesh to partition the use of
administration keys so that the consequences of losing an
administrative device can be mitigated.
Hallam-Baker Expires 30 December 2023 [Page 36]
Internet-Draft Mesh Architecture 3.0 June 2023
These techniques are currently being developed by the CFRG. This
work is currently described in [draft-irtf-cfrg-frost].
5.6. Data At Rest Encryption
The Data At Rest Encryption (DARE) format is used for all
confidentiality and integrity enhancements. The DARE format is based
on the JOSE Signature and Encryption formats and the use of an
extended version of the JSON encoding allowing direct encoding of
binary objects.
5.6.1. DARE Envelope
The DARE Envelope format offers similar capabilities to existing
formats such as OpenPGP and CMS without the need for onerous encoding
schemes. DARE Assertions are presented as DARE Envelopes.
A feature of the DARE Envelope format not supported in existing
schemes is the ability to encrypt and authenticate sets of data
attributes separately from the payload. This allows features such as
the ability to encrypt a subject line or content type for a message
separately from the payload.
5.6.2. Dare Sequence
A DARE Sequence is an append-only sequence of DARE Envelopes. A key
feature of the DARE Sequence format is that entries MAY be encrypted
and/or authenticated incrementally. Individual entries MAY be
extracted from a DARE Sequence to create a stand-alone DARE Envelope.
Sequences may be authenticated by means of a Merkle tree of digest
values on the individual frames. This allows similar demonstrations
of integrity to those afforded by Blockchain to be provided but with
much greater efficiency.
Unlike traditional encryption formats which require a new public key
exchange for each encrypted payload, the DARE Sequence format allows
multiple entries to be encrypted under a single key exchange
operation. This is particularly useful in applications such as
encrypting server transaction logs. The server need only perform a
single key exchange operation each time it starts to establish a new
shared secret for that session. The shared secret is then used to
create fresh symmetric keying material for each entry in the log
using a unique nonce per entry.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Hallam-Baker Expires 30 December 2023 [Page 37]
Internet-Draft Mesh Architecture 3.0 June 2023
Figure 5: DARE Sequence containing a transaction log.
Integrity is provided by a Merkle tree calculated over the sequence
of log entries. The tree apex is signed at regular intervals to
provide non-repudiation.
Four types of DARE Sequence are used in the mesh
Catalogs A DARE Sequence whose entries track the status of a set of
related objects which may be added, updated, or deleted.
Spools A DARE Sequence whose entries track the status of a series of
Mesh Messages.
Logs A DARE Sequence recording a sequence of events.
Archives A DARE Sequence containing a collection of files, each
encoded in a DARE envelope. DARE archives perform a similar
function to ZIP archives except that the primary objective is to
support confidentiality and integrity rather than data
compression.
5.7. Uniform Data Fingerprints.
The Uniform Data Fingerprint (UDF) format provides a compact means of
presenting cryptographic nonces, keys and digest values using Base32
encoding that resists semantic substitution attacks. UDF provides a
convenient format for data entry. Since the encoding used is case-
insensitive, UDFs may if necessary be read out over a voice link
without excessive inconvenience.
The following are examples of UDF values:
NA3F-EQAS-PCNR-B7T2-YC5T-GJLA-ZNRA
EN5H-Y5QJ-W62O-7OEC-4VEK-YKSB-GU
SAQJ-Q3WI-I2VY-LJJL-4AOE-NO46-6P5T-Y
MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN
AATU-V2VR-5MHY-54G3-OKRN-OC5J-AEZM
UDF content digests are used to support a direct trust model similar
to that of OpenPGP. Every Mesh Profile is authenticated by the UDF
fingerprint of its signature key. Mesh Friendly Names and UDF
Fingerprints thus serve analogous functions to DNS names and IP
Addresses. Like DNS names, Friendly Names provide the basis for
application-layer interactions while the UDF Fingerprints are used as
to provide the foundation for security.
Hallam-Baker Expires 30 December 2023 [Page 38]
Internet-Draft Mesh Architecture 3.0 June 2023
5.7.1. Friendly Names
Internet addressing schemes are designed to provide a globally unique
(or at minimum unambiguous) name for a host, service or account. In
the early days of the Internet, this resulted in addresses such as
10.2.3.4 and alice@example.com which from a usability point of view
might be considered serviceable if not ideal. Today the Internet is
a global infrastructure servicing billions of users and tens of
billions of devices and accounts are more likely to be
alice.lastname.1934@example.com than something memorable.
Friendly names provide a user or community specific means of
identifying resources that may take advantage of geographic location
or other cues to resolve possible ambiguity. If Alice says to her
voice activated device "close the garage door" it is implicit that it
is her garage door that she wishes to close. And should Alice be
fortunate enough to own two houses with a garage, it is implicit that
it is the garage door of the house she is presently using that she
wishes to close.
The Mesh Device Catalog provides a directory mapping friendly names
to devices that is available to all Alice's connected devices so that
she may give and instruction to any of her devices using the same
friendly name and expect consistent results.
5.7.2. Encrypted Authenticated Resource Locators
Various schemes have been used to employ QR Codes as a means of
device and/or user authentication. In many of these schemes a QR
code contains a challenge nonce that is used to authenticate the
connection request.
The Mesh supports a QR code connection mode employing the Encrypted
Authenticated Resource Locator (EARL) format. An EARL is an
identifier which allows an encrypted data object to be retrieved and
decrypted. In this case, the encrypted data object contains the
information needed to complete the interaction.
An EARL contains the domain name of the service providing the
resolution service and an encryption master key:
mcu://maker@example.com/ECHI-CYLR-Y22Q-6OME-OAWV-WIQD-YM
The EARL may be expressed as a QR code:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Hallam-Baker Expires 30 December 2023 [Page 39]
Internet-Draft Mesh Architecture 3.0 June 2023
Figure 6: QR Code representation of the EARL
An EARL is resolved by presenting the content digest fingerprint of
the encryption key to a Web service hosted at the specified domain.
The service returns a DARE Envelope whose payload is encrypted and
authenticated under the specified master key. Since the content is
stored on the service under the fingerprint of the key and not the
key itself, the service cannot decrypt the plaintext. Only a party
that has access to the encryption key in the QR code can decrypt the
message.
5.7.3. Secure Internet Names
Secure Internet Names bind an Internet address such as a URL or an
email address to a Security Policy by means of a UDF content digest
of a document describing the security policy. This binding enables a
SIN-aware Internet client to ensure that the security policy is
applied when connecting to the address. For example, ensuring that
an email sent to an address must be end-to-end encrypted under a
particular public key or that access to a Web Service requires a
particular set of security enhancements.
alice@example.com Alice's regular email address (not a SIN).
alice@mm--mb3t-wipz-jrcw-qzfm-scql-ovvo-aho2.example.com A strong
email address for Alice that can be used by a regular email
client.
alice@example.com.mm--mb3t-wipz-jrcw-qzfm-scql-ovvo-aho2 A strong
email address for Alice that can only used by an email client that
can process SINs.
Using an email address that has the Security Policy element as a
prefix allows a DNS wildcard element to be defined that allows the
address to be used with any email client. Presenting the Security
Policy element as a suffix means it can only be resolved by a SIN-
aware client.
5.8. Personal Key Escrow
One of the core objectives of the Mesh is to make data level
encryption ubiquitous. While data level encryption provides robust
protection of data confidentiality, loss of the ability to decrypt
means data loss.
For many Internet users, data availability is a considerably greater
concern than confidentiality. Ten years later, there is no way to
replace pictures of the children at five years old. Recognizing the
Hallam-Baker Expires 30 December 2023 [Page 40]
Internet-Draft Mesh Architecture 3.0 June 2023
need to guarantee data recovery, the Mesh provides a robust personal
key escrow and recovery mechanism. Lawful access is not supported as
a requirement.
Besides supporting key recovery in the case of loss, the Mesh
protocols potentially support key recovery in the case of the key
holder's death. The chief difficulty faced in implementing such a
scheme being developing an acceptable user interface which allows the
user to specify which of their data should survive them and which
should not. As the apothegm goes: Mallet wants his beneficiaries to
know where he buried Aunt Agatha's jewels but not where he buried
Aunt Agatha.
The Mesh supports use of Shamir/Lagrange secret sharing and recovery
to split a secret key into a set of shares, a predetermined number of
which may be used to recover the original secret. For convenience
secret shares are represented using UDF allowing presentation in
Base32 (i.e. text format) for easy transcription or QR code
presentation if preferred.
To facilitate escrow and recovery, all the public key pairs and key
shares associated with a Mesh profile are generated from a seed value
using a deterministic algorithm. Thus, escrow of the seed value is
sufficient to permit recovery of the private key data.
For example, Alice escrows her Mesh Profile creating three recovery
shares, two of which are required to recover the master secret:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 7: Use of Shamir/Lagrange Secret Sharing to create a
recovery record.
To recover the master secret, Alice presents the necessary number of
key shares. These are used to recover the master secret which is
used to generate the decryption key:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 8: Use of Shamir/Lagrange Secret Recovery to recover a
master key set.
A user may choose to store their encrypted recovery record themselves
or make use of the EARL mechanism to store the information at one or
more cloud services using the fingerprint of the master secret as the
locator.
Hallam-Baker Expires 30 December 2023 [Page 41]
Internet-Draft Mesh Architecture 3.0 June 2023
6. Mesh Architecture
The Mesh infrastructure is supported by a compact set of structures
and protocols. These are discussed in detail in the Schema Reference
[draft-hallambaker-mesh-schema] and Protocol Reference
[draft-hallambaker-mesh-protocol] documents.
The JSON object model and JSON or JSON-B serialization
[draft-hallambaker-jsonbcd] are used for all Mesh data structures.
These include:
Assertions A DARE envelope containing a signed data object.
Assertions include Profiles and Connections.
Profile A self-signed assertion describing a Mesh principal.
Principals include Accounts, Devices and Services.
Every profile specifies a profile signature key under which it is
signed. The UDF fingerprint of the profile signature key is used
as a unique identifier for the profile. Thus, all attributes
declared in the profile such as authentication keys and encryption
keys are bound to the unique identifier for the profile.
Connection An assertion signed by one principal delegating rights to
another. Connection assertions are used to bind devices to
accounts and hosts to a service.
Activation A DARE envelope encrypted under the encryption key of a
principal that grant rights or capabilities to that principal.
This is typically but not always achieved through use of threshold
key techniques.
Message A DARE envelope signed by the sender that is encrypted under
the encryption key of the intended recipient(s) whose content is a
Mesh messaging object.
Entry An object stored in a catalog that carries an identifier that
is unique for that catalog.
6.1. Actors
Three Mesh actors are defined: Accounts, Devices and Services. Each
of these is described by a specific type of profile.
Hallam-Baker Expires 30 December 2023 [Page 42]
Internet-Draft Mesh Architecture 3.0 June 2023
6.1.1. Account
Two types of Mesh account are currently specified: personal accounts
and group accounts. For concise exposition, this document is limited
to the description of personal accounts. Group accounts are
specified in the Schema Reference [draft-hallambaker-mesh-schema].
A Mesh account is an abstraction which may be loosely regarded as the
thing to which a collection of devices (in the case of a user
account) or a collection of members (in the case of a group account)
belong.
Each personal account profile specifies:
Profile Signature Key Used to authenticate the profile. Updates to
the profile require use of the Profile Signature Key. The Profile
Signature Key cannot be changed but a profile may be replaced by a
new profile.
Uniform Data Fingerprint The UDF fingerprint of the Profile
Signature Key. This is used as a unique identifier for the
account.
Account Name The account name through which the profile is serviced.
Administration Keys UDF fingerprint of keys that are authorized to
sign device connection assertions and update the Device Catalog.
Signature Key Public parameters of the account signature key. This
is the key that counterparties will use to verify messages sent by
the account holder.
Encryption Key Public parameters of the account encryption key.
This is the key that counterparties will use to encrypt messages
sent to the account holder.
Authentication Key Public parameters of the account authentication
key. This is the key that counterparties will use to establish
authenticated exchanges with the account holder.
The public keys for encryption, authentication and signature
specified in the account profile are the only keys that will (in
normal circumstances) be visible to other Mesh accounts.
Hallam-Baker Expires 30 December 2023 [Page 43]
Internet-Draft Mesh Architecture 3.0 June 2023
6.1.2. Device
A Mesh Device is any device that is connected to a Mesh Account
through a Device profile. A given physical device may have multiple
device profiles associated with it but for the purposes of the Mesh,
these are considered to be separate devices. A given device profile
may be connected to more than one account
The device profile specifies:
Profile Signature Key Used to authenticate the profile. Updates to
the profile require use of the Profile Signature Key. The Profile
Signature Key cannot be changed but a profile may be replaced by a
new profile.
Uniform Data Fingerprint The UDF fingerprint of the Profile
Signature Key. This is used as a unique identifier for the device.
Signature Key Public parameters of the device signature key share.
This key share is used as a contribution to the signature key the
device will use in the context of the account and to authenticate
device connection requests.
Encryption Key Public parameters of the account encryption key
share. This key share is used as a contribution to the encryption
key the device will use in the context of the account and to
decrypt activation records sent in response to device connection
requests.
Authentication Key Public parameters of the account authentication
key share. This key share is used as a contribution to the
authentication key the device will use in the context of the
account.
Description Optional information describing the device provided by
the manufacturer. E.g. model, serial number, date of manufacture
etc.
A Mesh Device is connected to an account through the creation of an
activation record and a connection record.
The activation record contains key shares that are overlaid on the
corresponding shares specified in the device profile to create the
set of encryption, authentication and signature keys the device will
use in the context of the account. Since the private keys
corresponding to the device profile keys are only used to enable the
connection of the device to an account, these keys are only trusted
to a minimal degree.
Hallam-Baker Expires 30 December 2023 [Page 44]
Internet-Draft Mesh Architecture 3.0 June 2023
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 9: Activation of an account key set.
In the ideal case, the device profile keys are fixed to the device
such that they may be used to perform private key operations without
the ability to extract the private key data from the device. Since
the device profile is only trusted for the limited purpose of
connecting the device to an account, the device profile may be
created during manufacture without undue concern for either
disclosure of the private key on the part of the account holder or a
reputation attack alleging disclosure of the private key on the part
of the manufacturer.
The device connection record is functionally a certificate that the
device may use to interact with the Mesh Service or to other devices
connected to the same account. Note however that use of threshold
cryptography means that Mesh devices would not normally present their
device connection record to any other party since all communication
with external parties takes place through the keys published in the
account profile.
6.1.3. Service
A Mesh Service is an abstract network service that is provided by one
or more hosts. The properties of the service are described by the
service profile.
The service profile specifies:
Profile Signature Key Used to authenticate the profile. Updates to
the profile require use of the Profile Signature Key. The Profile
Signature Key cannot be changed but a profile may be replaced by a
new profile.
Uniform Data Fingerprint The UDF fingerprint of the Profile
Signature Key. This is used as a unique identifier for the device.
Signature Key Public parameters of the service signature key. This
is the key that counterparties will use to verify messages sent by
the service.
Encryption Key Public parameters of the service encryption key.
This is the key that counterparties will use to encrypt messages
sent to the service.
Authentication Key Public parameters of the account authentication
Hallam-Baker Expires 30 December 2023 [Page 45]
Internet-Draft Mesh Architecture 3.0 June 2023
key. This is the key that counterparties will use to establish
authenticated exchanges with the service.
Hosts are Mesh Devices that have been granted a Host Activation and
Host Connection by a service administrator. These are used in the
same fashion as the device activation and connection records.
6.2. Stores
Mesh Stores are append-only sequences that are used to represent
collections of objects, messages and data. All Mesh stores are
implemented as DARE Sequences authenticated by means of a Merkle
tree. The payload of each envelope in the sequence is usually
encrypted.
Two types of Mesh store are currently defined:
Catalog A set of Mesh objects, each of which has an identifier that
is unique in the scope of the catalog. Objects may be added,
updated, and deleted.
Spool A sequence of Mesh Messages.
All the state represented within a Mesh account is contained in Mesh
stores bound to the account. Thus, to synchronize a device to the
state of the account, it is sufficient to synchronize the collection
of stores the device is permitted to read. Since every store is an
append-only sequence, it is sufficient for the Mesh service to return
the envelopes added to each of the stores since the device was last
synchronized.
Rapid synchronization of catalogs and spools is ensured by limiting
the size of entries to each. Implementations may further improve
performance by redacting stores to remove obsolete entries that have
been updated or deleted. Alternatively, a device may maintain a
complete record of the state of the store to allow erroneous changes
to the store to be unwound.
6.2.1. Catalogs
Mesh Catalogs track a collection of entries. Every Mesh account
contains a Threshold Catalog that is used by Mesh services as the
source of access control policy. The Threshold Catalog is unique in
that it is the only catalog whose contents can be read by the Mesh
Service. Every other Mesh Catalog connected to a Mesh account is
end-to-end encrypted so that it can only be read by devices connected
to the account.
Hallam-Baker Expires 30 December 2023 [Page 46]
Internet-Draft Mesh Architecture 3.0 June 2023
The Mesh specifies various catalogs that are used to track
information relevant to a Mesh Account:
Device The devices connected to the corresponding Mesh profile.
Contact Logical and physical contact information for people and
organizations.
Bookmark Web bookmarks and citations.
Credential Username and password information for network resources.
Calendar Appointments and tasks.
Network Network access configuration information allowing access to
wireless networks and VPNs.
Application Configuration information for applications including
mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH.
Access A catalog that is readable by the Mesh Service that is used
to determine access to account resources including device access
rights, threshold keys and message delivery.
Each catalog connected to an account has a unique identifier of the
form mmm_<<name>. Applications may specify additional catalogs
without risk of collision with future Mesh catalogs by using an
appropriate IANA assigned protocol label.
6.2.2. Spools
Spools are used to track inbound and outbound messages. Three spools
are currently defined:
Inbound Messages that have been received by the service and accepted
for delivery to the account.
Outbound Messages that have been sent from the account through the
service.
Local A spool used to exchange messages with devices connecting to
the device.
Hallam-Baker Expires 30 December 2023 [Page 47]
Internet-Draft Mesh Architecture 3.0 June 2023
6.3. Mesh Service Protocol
Mesh services communicate with Mesh devices and other Mesh Services
through the Mesh Service Protocol. Despite the wide range of Mesh
functionality, the Mesh protocol is remarkably compact. The bulk of
the semantics associated with the Mesh are expressed in the schemas
describing Mesh Messages and Catalogs. The objective of reducing the
degree of trust in the Mesh service to the absolute minimum by
necessity requires that the Mesh Service be extremely simple.
Mesh Service Protocol transactions are divided into the following
groups:
Service Description The Hello transaction returns a description of
the service including information used to authenticate future
interactions with the service.
Account Management The Create and Delete transactions are used to
bind an account to a service.
Device Connection The Connect and Complete transactions are used to
connect devices to an account
Synchronization The Status, Download and Transact transactions are
used to update stores connected to an account.
Messaging The Post transaction is used by one Mesh Service to
transfer a message from one of its users to a different Mesh
Service serving one of the recipients.
Publication The Publish, Claim and PollClaim transactions are used
to publish and retrieve data objects through an account.
Cryptographic The Operate transaction requests that the service
performs a cryptographic operation on behalf of the account. This
is used to provide execution of threshold operations on behalf of
the account holder for both internal and external users.
Future versions of the Mesh Service Protocol may support additional
transactions to support features such as providing DNS resolution.
Hallam-Baker Expires 30 December 2023 [Page 48]
Internet-Draft Mesh Architecture 3.0 June 2023
6.3.1. Protocol Interactions
Every Mesh Service Protocol transaction consists of a single request
from a Mesh client followed by a single response. Requests and
responses are authenticated and encrypted under a key established
between the client and the service. This application layer
enhancement is in addition to any transport layer enhancement that
may be employed (e.g. TLS).
Mesh Service Protocol messages may be exchanged through any binding
advertised by the service by means of the Hello transaction.
Currently only one binding is defined, mapping Mesh requests and
responses to the content data of HTTP POST requests and responses
layers over a TLS transport.
While the use of up to three layers of encryption may be regarded as
excessive, each layer provides separate protections:
Transport Layer Provides confidentiality for metadata and limited
traffic analysis protections.
Application Layer Encryption and authentication of requests and
responses using keys bound to the specific device and service
performing the interaction provides the basis for access control.
Data Layer Encryption of stored data (catalog data, device
activations, etc.) provides end to end security between the
devices connected to the account.
6.4. The Access Catalog
The Access Catalog of a Mesh account is the only catalog whose
payload contents are readable by the service. This is necessary
because the catalog provides the sole source for the authorization
component of the access control policy for the account.
Each entry in the catalog specifies an operation that the service
will perform when it receives a request that is authenticated and
authorized by the access control policy specified in the entry.
Operations include:
Service Provision Account operations such as operations on stores
(Status, Download, Transact) require that the client be
authenticated by means of an authentication key that has a
matching entry in the Access catalog that authorizes the
operation.
Inbound Message Filtering Messages received by the service that
Hallam-Baker Expires 30 December 2023 [Page 49]
Internet-Draft Mesh Architecture 3.0 June 2023
match the specified criteria will be appended to the inbound
message spool.
Threshold Key Generation Performs a threshold key splitting
operation of a private key held by the service and encrypts one
part under a key known only to the service and encrypts the other
under a public key specified by the party making the request.
Key Agreement Performs a key agreement operation on a private key
held by the service. This may be used as a component in a
threshold key agreement scheme.
Signature Performs a signature operation on a private key held by
the service. This may be used as a component in a threshold
signature scheme.
These operations provide the vocabulary from which a Threshold Key
Infrastructure is built. Keys that are bound to a service using
threshold techniques can only be applied with the co-operation of
that service.
6.5. Mesh Messaging Protocol
Mesh devices connected to an account interact with the Mesh Service
through the Mesh Service protocol. Mesh devices interact with other
Mesh devices through the Mesh Messaging Protocols, each of which
provides a distinct application functionality:
* Connection Protocol
* Confirmation Protocol
* Contact Exchange Protocol
Each of these protocols is described in depth in the Mesh Protocol
Reference [draft-hallambaker-mesh-protocol].
Mesh Messages provide a means of communication between Mesh Service
Accounts with capabilities that are not possible or poorly supported
in traditional SMTP mail messaging:
* End-to-end confidentiality and authentication by default.
* Abuse mitigation by applying access control to every inbound and
outbound message.
* End-to-end secure group messaging.
Hallam-Baker Expires 30 December 2023 [Page 50]
Internet-Draft Mesh Architecture 3.0 June 2023
* Transfer of exceptionally large data sets (Terabytes).
Note that although Mesh Messaging is designed to facilitate the
transfer of very large data sets, the size of Mesh Messages
themselves is severely restricted. The current default maximum size
being 64 KB. This approach allows Mesh
In addition, the platform anticipates but does not currently support
additional cryptographic security capabilities:
* Traffic analysis resistance using mix networks (Chaum).
* Simultaneous contract binding using fair contract signing
(Micali).
While these capabilities might in time cause Mesh Messaging to
replace SMTP, this is not a near term goal. The short-term goal of
Mesh Messaging is to support the Contact Exchange and Confirmation
applications.
Two important classes of application that are not currently supported
directly are payments and presence. While prototypes of these
applications have been considered, it is not clear if these are best
implemented as special cases of the Confirmation and Contact Exchange
applications or as separate applications in their own right.
Messages exchanged between Mesh Users MUST be mediated by a Mesh
Service for both sending and receipt. This 'four corner' pattern
permits ingress and egress controls to be enforced on the messages
and that every message is properly recorded in the appropriate
spools.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 10: Four Corner Messaging Model
For example, to send a message to Alice, Bob posts it to one of the
Mesh Services connected to the Mesh Account from which the message is
to be sent. The Mesh Service checks to see that both the message and
Bob's pattern of behavior comply with their acceptable use policy and
if satisfactory, forwards the message to the receiving service
example.com.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 11: Performing Access Control on Outbound Messages
Hallam-Baker Expires 30 December 2023 [Page 51]
Internet-Draft Mesh Architecture 3.0 June 2023
The receiving service uses the recipient's contact catalog and other
information to determine if the message should be accepted. If
accepted, the message is added to the recipient's inbound message
spool to be collected by her device(s) when needed.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 12: Performing Access Control on Inbound Messages
For efficiency and to limit the scope for abuse, all inbound Mesh
Messages are subject to access control and limited in size to 32KB or
less. This limit has proved adequate to support transfer of complex
control messages and short content messages. Transfer of data
objects of arbitrary size may be achieved by sending a control
message containing a URI for the main content which may then be
fetched using a protocol such as HTTP.
This approach makes transfers of exceptionally large data sets (i.e.
multiple Terabytes) practical as the 'push' phase of the protocol is
limited to the transfer of the initial control message. The bulk
transfer is implemented as a 'pull' protocol allowing support for
features such as continuous integrity checking and resumption of an
interrupted transfer.
6.6. Using the Mesh with Applications
The Mesh provides an infrastructure for supporting existing Internet
security applications and a set security features that may be used to
build new ones.
For example, Alice uses the Mesh to provision and maintain the keys
she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the
credential catalog for end-to-end secure management of the usernames
and passwords for her Web browsing and other purposes:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-architecture-22.html for artwork.)
Figure 13: Each of Alice's devices have access to the shared
context of her personal account.
The Mesh design is highly modular allowing components that were
originally designed to support a specific requirement within the Mesh
to be applied generally.
Hallam-Baker Expires 30 December 2023 [Page 52]
Internet-Draft Mesh Architecture 3.0 June 2023
6.6.1. Future Applications
Since a wide range of network applications may be reduced to
synchronization of sets and lists, the basic primitives of Catalogs
and Spools may be applied to achieve end-to-end security in an even
wider variety of applications.
For example, a Spool may be used to maintain a mailing list, track
comments on a Web forum or record annotations on a document.
Encrypting the sequence entries under a multi-party encryption group
allows such communications to be shared with a group of users while
maintaining full end-to-end security and without requiring every
party writing to the spool to know the public encryption key of every
recipient.
Another interesting possibility is the use of DARE Sequences as a
file archive mechanism. A single signature on the final Merkle Tree
digest value would be sufficient to authenticate every file in the
archive. Updates to the archive might be performed using the same
sequence synchronization primitives provided by a Mesh Service. This
approach could afford a robust, secure, and efficient mechanism for
software distribution and update.
7. Security Considerations
The security considerations for use and implementation of Mesh
services and applications are described in the Mesh Security
Considerations guide [draft-hallambaker-mesh-security].
8. IANA Considerations
This document does not contain actions for IANA
9. Acknowledgements
Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin
Alden, Michael Richardson.
Appendix A: Outstanding Issues
The following issues need to be addressed.
Hallam-Baker Expires 30 December 2023 [Page 53]
Internet-Draft Mesh Architecture 3.0 June 2023
+==========+====================================+
| Issue | Description |
+==========+====================================+
| Recovery | Expand explanation and example to |
| | show applications being recovered. |
+----------+------------------------------------+
Table 1
10. Normative References
[draft-hallambaker-jsonbcd]
Hallam-Baker, P., "Binary Encodings for JavaScript Object
Notation: JSON-B, JSON-C, JSON-D", Work in Progress,
Internet-Draft, draft-hallambaker-jsonbcd-23, 23 October
2022, <https://datatracker.ietf.org/doc/html/draft-
hallambaker-jsonbcd-23>.
[draft-hallambaker-mesh-callsign]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Mesh
Callsign Service", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-callsign-02, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-callsign-02>.
[draft-hallambaker-mesh-cryptography]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII:
Cryptographic Algorithms", Work in Progress, Internet-
Draft, draft-hallambaker-mesh-cryptography-10, 23 October
2022, <https://datatracker.ietf.org/doc/html/draft-
hallambaker-mesh-cryptography-10>.
[draft-hallambaker-mesh-dare]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data
At Rest Encryption (DARE)", Work in Progress, Internet-
Draft, draft-hallambaker-mesh-dare-16, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-dare-16>.
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-developer-10, 27 July 2020,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-developer-10>.
Hallam-Baker Expires 30 December 2023 [Page 54]
Internet-Draft Mesh Architecture 3.0 June 2023
[draft-hallambaker-mesh-notarization]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part IX: Mesh
Notarized Signatures", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-notarization-00, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-notarization-00>.
[draft-hallambaker-mesh-platform]
Hallam-Baker, P., "Mathematical Mesh: Platform
Configuration", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-platform-06, 27 July 2020,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-platform-06>.
[draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol
Reference", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-protocol-14, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-protocol-14>.
[draft-hallambaker-mesh-rud]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Reliable
User Datagram", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-rud-02, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-rud-02>.
[draft-hallambaker-mesh-schema]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema
Reference", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-schema-11, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-schema-11>.
[draft-hallambaker-mesh-security]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part IX Security
Considerations", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-security-09, 20 April 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-security-09>.
[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform
Data Fingerprint.", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-udf-17, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-udf-17>.
Hallam-Baker Expires 30 December 2023 [Page 55]
Internet-Draft Mesh Architecture 3.0 June 2023
[draft-hallambaker-threshold]
Hallam-Baker, P., "Threshold Modes in Elliptic Curves",
Work in Progress, Internet-Draft, draft-hallambaker-
threshold-08, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
threshold-08>.
[draft-hallambaker-web-service-discovery]
Hallam-Baker, P., "DNS Web Service Discovery", Work in
Progress, Internet-Draft, draft-hallambaker-web-service-
discovery-08, 23 October 2022,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
web-service-discovery-08>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/rfc/rfc7159>.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/rfc/rfc7231>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/rfc/rfc7516>.
11. Informative References
Hallam-Baker Expires 30 December 2023 [Page 56]
Internet-Draft Mesh Architecture 3.0 June 2023
[draft-hallambaker-mesh-trust]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part X: The Trust
Mesh", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-trust-09, 5 August 2021,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-trust-09>.
[draft-irtf-cfrg-frost]
Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood,
"Two-Round Threshold Schnorr Signatures with FROST", Work
in Progress, Internet-Draft, draft-irtf-cfrg-frost-13, 8
May 2023, <https://datatracker.ietf.org/doc/html/draft-
irtf-cfrg-frost-13>.
Hallam-Baker Expires 30 December 2023 [Page 57]
