Internet DRAFT - draft-hallambaker-cryptomesh
draft-hallambaker-cryptomesh
Internet Engineering Task Force (IETF) Phillip Hallam-Baker
INTERNET-DRAFT Comodo Group Inc.
Intended Status: Standards Track June 29, 2015
Expires: December 31, 2015
Modular Mathematical Mesh
draft-hallambaker-cryptomesh-00
Abstract
The Magic Mathematical Mesh 'the Mesh' is a security infrastructure
for the Internet that puts individual users in control of their
security. Through large scale redundancy and replication techniques,
mesh users have a high level of assurance that data stored in the
mesh through a mesh gateway node will be available at a later date.
The mesh does not offer confidentiality guarantees. All data in the
mesh is assumed to be public. Confidential data stored in the mesh
must be protected using strong encryption. The mesh provides a medium
that enables the exchange of private key data but never passes
private data of any form in plaintext form.
The mesh enables use of end-to-end and transport security with mutual
authentication in a wide range of client server and peer-peer
applications. These include email, remote access and the Web. Unlike
previous attempts to establish such infrastructures, the password
management application supported by the mesh delivers users with an
immediate benefit that does not rely on adoption by others.
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 http://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."
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
Hallam-Baker December 31, 2015 [Page 1]
Internet-Draft Modular Mathematical Mesh June 2015
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hallam-Baker December 31, 2015 [Page 2]
Internet-Draft Modular Mathematical Mesh June 2015
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. What does the Mesh do for me? . . . . . . . . . . . . . . 7
2.1.1. User Experience . . . . . . . . . . . . . . . . . . 8
2.1.2. What else can the Mesh do for me in the future? . . 9
2.2. No-Password Authentication . . . . . . . . . . . . . . . 10
2.3. Encrypted Email . . . . . . . . . . . . . . . . . . . . . 10
2.4. WiFi and Networking . . . . . . . . . . . . . . . . . . . 11
2.5. Internet of Things . . . . . . . . . . . . . . . . . . . 11
2.6. Developer Tools . . . . . . . . . . . . . . . . . . . . . 12
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Personal Profile . . . . . . . . . . . . . . . . . . 13
3.1.2. Device Profile . . . . . . . . . . . . . . . . . . . 15
3.2. Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Offline Escrow . . . . . . . . . . . . . . . . . . . 16
3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Object Identifiers . . . . . . . . . . . . . . . . . 16
3.3.2. Account Identifier . . . . . . . . . . . . . . . . . 17
3.3.3. Profile Identifier URI . . . . . . . . . . . . . . . 17
4. Application Profiles . . . . . . . . . . . . . . . . . . . . . 18
4.1. Administration . . . . . . . . . . . . . . . . . . . . . 18
4.2. Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Network Connection . . . . . . . . . . . . . . . . . . . 18
4.4. Password Manager . . . . . . . . . . . . . . . . . . . . 19
4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 19
4.6. Email . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Mesh Log . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Mesh Replication . . . . . . . . . . . . . . . . . . . . 21
6. Requirements and Recommendations . . . . . . . . . . . . . . . 21
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Mesh Integrity . . . . . . . . . . . . . . . . . . . . . 22
7.2. Mesh Data Confidentiality . . . . . . . . . . . . . . . . 22
7.3. Disclosure of Private Key . . . . . . . . . . . . . . . . 23
7.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 23
7.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23
7.6. Covert Channels . . . . . . . . . . . . . . . . . . . . . 23
7.7. Data Loss . . . . . . . . . . . . . . . . . . . . . . . . 24
7.8. User Capture . . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Registration of mmm URI Scheme (provisional) . . . . . . 24
8.2. Registration of application/mesh Content Types . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Hallam-Baker December 31, 2015 [Page 3]
Internet-Draft Modular Mathematical Mesh June 2015
Hallam-Baker December 31, 2015 [Page 4]
Internet-Draft Modular Mathematical Mesh June 2015
1. Definitions
1.1. 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].
1.2. Defined Terms
Mesh Object
A collection of data items stored in the mesh with a unique
and fixed identifier.
Mesh Entry
An entry in the mesh recording the value of a mesh object at
a particular instant.
Profile
A mesh object that contains
Personal Profile
A profile that contains a description of a user?s personal
PKI, credentials and connected devices and applications.
Device Profile
A profile that contains a description of a device and its
associated credentials.
Application Profile
A profile that contains a description of the use of an
application by a user
Enterprise Profile
A profile that contains a description of a enterprise?s PKI,
credentials and connected devices and applications.
Mesh Node
One or more host machines that provide mesh services under
the same domain name and share the same state.
Gateway Node
A Mesh node that supports services that append data to the
Mesh.
Distribution Node
A Mesh node that supports services that report but do not
change the state of the Mesh.
Hallam-Baker December 31, 2015 [Page 5]
Internet-Draft Modular Mathematical Mesh June 2015
Mesh
A collection of interlinked Mesh Nodes exchanging data
through the replication protocol so as to present a single
consistent repository for all mesh
Public Key
Non-secret portion of a public key pair.
Private Key
Secret portion of a public key pair.
Fingerprint
The output of a cryptographic digest function presented in a
form that facilitates verification that the original data
input is unchanged.
Public Profile
A profile or portion of a profile containing plaintext data.
Private Profile
A profile or portion of a profile containing encrypted data.
2. Introduction
The Magic Mathematical Mesh 'the Mesh' is a security infrastructure
for the Internet that puts individual users in control of their
security. The Mesh is based on three principles:
Magic
From the point of view of the user, the mesh should appear
to work 'by magic'. Visiting a Web site secured using https
requires no more effort from the user than visiting an
insecure site. That principle of 'security by magic' should
apply to every interaction.
Mathematical
The mesh provides security through the use of cryptography.
Users do not need to understand the mathematics that make
the mesh work but every part of the mathematics supporting
the mesh must be public and fully documented.
Mesh
The mesh itself is a decentralized cloud service similar to
the blockchain that supports BitCoin. Like the services that
support the blockchain, every operation on the mesh is
public and the integrity of the mesh is preserved by means
of a hash chain mechanism. The mesh does not store or have
access to any confidential plaintext data of any kind
including private keys. Once information has been replicated
across the surface of the mesh, it cannot be deleted without
the collusion of every mesh node and without the originator
Hallam-Baker December 31, 2015 [Page 6]
Internet-Draft Modular Mathematical Mesh June 2015
being able to detect the default.
While constructing such an infrastructure would have been considered
an absurd challenge in 1995, the success of BitCoin provides a
demonstration that deploying infrastructures of this size is now both
practical and possible.
The indexed Web contains over 4.6 billion pages and 5 zettabytes of
data and both are growing at an exponential rate. To serve its
function, the mesh need only store a personal profile of a few tens
of kilobytes for each person on the planet. A single desktop RAID
array could store a personal profile for every one of the three
billion users of the Web today.
2.1. What does the Mesh do for me?
Today the World Wide Web has thousands of uses from information
retrieval to online banking to turning light switches on and off in
the home. But the original success of the Web at CERN was came from
serving just one function and doing that very well: Providing access
to the CERN phoned directory.
Today's Internet users have myriad security desires and even greater
needs. They want encrypted mail; they want encrypted documents; they
want encrypted Web sites. But the single biggest security related
aggravation is the need to remember usernames and passwords for
hundreds of individual Web Sites. Attempts to solve this problem to
date have focused on two particular strategies:
* Persuade users to store all their passwords in a network
accessible service.
* Persuade Web site providers to use an external 'identity
service' to perform account management for them.
Both approaches have major flaws as the recent breach at LastPass and
Google's decision to drop support for OpenID 2.0 demonstrate. If a
Web Site decides to outsource identity management to a third party
they are making their business dependent on that third party
operating their infrastructure securely and continuing to do business
in a particular way.
Storing account credentials in the mesh overcomes the problems
associated with both legacy approaches:
* The mesh is not a trusted service. The mesh cannot be
breached because the mesh does not offer any security
guarantees. The security of mesh applications depends on the
security of the end points, not the security of the mesh.
Hallam-Baker December 31, 2015 [Page 7]
Internet-Draft Modular Mathematical Mesh June 2015
* All data stored in the mesh is encrypted, including
usernames and passwords.
* Decrypting data stored in the mesh always requires
information stored outside the mesh.
* The mesh is not a restricted service. Anyone can set up a
mesh at any time and anyone can distribute an established
public mesh.
* Mesh users connect through a mesh gateway. By definition, a
public mesh has multiple gateway providers and can change
their gateway at any time.
* Mesh users can always recover the information assets they
stored, either from local storage or from a mesh
distributor.
* The only necessary requirement for a mesh gateway is to
impose some form of abuse limiting mechanism to stop denial
of service attack against the mesh by flooding it with bogus
data.
Although the primary purpose of this proposal is to establish a
single cryptomesh as a ubiquitous public infrastructure analogous to
the Internet, DNS and the WebPKI, it is recognized that such
infrastructures are more likely to grow organically rather than
through a top-down approach. Reflecting this approach, the mesh is
conceived as a collection of loosely coupled nodes, each of which is
independently hosted and operated.
A mesh gateway node may assure users that their data is protected in
the event of a permanent or temporary loss of service at that node by
establishing replication agreements with one or more independent
nodes. Such agreements may be reasonably expected to encourage the
emergence of a single public mesh over time.
2.1.1. User Experience
A personal profile is created using the profile management tool. In
quickstart mode the user need provide nothing more than an account
name for the profile and the domain of a mesh gateway (e.g.
comodo.com). Even the account name is not strictly necessary unless
the user has more than one profile. It just proved easier for users
to ask than making this an option. The second can be given by default
with a user override option.
Whenever a new profile is created, the profile manager reports a
profile fingerprint. This is conceptually similar to an OpenPGP key
but with the important distinction of not being limited to a single
application. Once a profile is generated, its fingerprint never
Hallam-Baker December 31, 2015 [Page 8]
Internet-Draft Modular Mathematical Mesh June 2015
changes. The profile fingerprint is used when connecting new devices
to a profile to ensure that the correct device is being connected and
not an impostor. While at present fingerprints are Base32 encoded
alphanumeric strings, other formats such as a sequence of images may
be used for verification.
Since a new profile does not contain any data at all, the user may
skip the key escrow option. Otherwise the master signature and
decryption keys for the profile are encrypted under a symmetric key
and stored in a private profile. The symmetric key is then split
using Shamir secret sharing and each share presented to the user as
an alphanumeric recovery key and/or QR code. These may be printed and
stored in case recovery should be required.
Once a profile has been established, a mesh enabled application
running on the same device may use it automatically or after
requesting user consent. Thus a mesh enabled password manager might
prompt the user to ask if they wanted to store usernames and
passwords in their mesh profile.
To make use of an existing profile on a second device, a user starts
the profile manager and gives the account name. The profile manager
displays the profile fingerprint for verification purposes. When the
user runs the profile manager on a machine that has been connected to
the profile already and granted administration privileges, it
displays a list of pending connection requests which may be approved
or declined as the user decides. Once the request is approved, the
user will have full access to their passwords stored in the crypto
mesh on the second machine.
Even though the user experience of a mesh based password manager is
no more complicated than that of a traditional scheme, no
confidential data is ever passed unencrypted through the mesh and all
encryption is end to end and uses the strongest level of AES
encryption. The mesh is thus immune to the risk of breach since there
is no information to be breached.
More importantly, once a user has made the effort of installing a
mesh profile manager, they have the tools at their disposal to use
the mesh with any application that is mesh-enabled. By design, the
mesh supports any application that uses cryptographic credentials.
2.1.2. What else can the Mesh do for me in the future?
Use of the Web at CERN began with the phone book. But that use alone
would not have been enough to justify the effort of developing the
tool. The reason CERN was willing to invest the time and effort
required to build the Web was the understanding that it would one day
be capable of doing much more.
Hallam-Baker December 31, 2015 [Page 9]
Internet-Draft Modular Mathematical Mesh June 2015
While the CERN phone book was the 'killer application' of the Web on
CERN main site, the Web itself was originally designed to enable
distribution of research materials. In the same way, secure password
storage represents a 'killer application' that requires no other
party to buy-in or make use of the mesh in order to build out the
infrastructure. But it is sincerely hoped that once that
infrastructure is established it will enable second generation
applications that are far more useful.
The mesh provides a mechanism for storing and retrieving profiles. In
this paper we only consider the profile types relevant to one
particular mesh, the cryptographic mesh (cryptomesh) used to store
cryptographic credentials and other data relevant to enabling use of
applications. Since strong cryptographic keys need only be tens or
hundreds of bytes, such profiles would typically be very small, a few
tens or hundreds of kilobytes at most. But given suitable storage
capability, the same technology used to build the cryptomesh could
also be applied to storage of data (aka the datamesh).
2.2. No-Password Authentication
Making passwords easier to use is good. But the getting rid of them
entirely is better. There is no little irony in the fact that after
rendering the telephone book obsolete, the Internet quickly rendered
the public telephone network obsolete. It would be the greatest
service if the mesh could render passwords obsolete as a network
authentication mechanism.
There is no shortage of protocols and mechanisms that eliminate the
need for password authentication. The chief deployment obstacle has
been the lack of support infrastructure. Until there is a large
population of Web users equipped with the means to use a password
alternative, there is no incentive for Web sites to accept
alternatives. And until Web sites accept alternatives there is no
incentive for users to change their behavior.
The mesh provides a mechanism that allows every device a user owns to
be provisioned with a public key pair and credential chain. This
allows the use of existing protocols such as SAML and OpenID Connect
to be used to replace passwords completely.
Instead of being asked to provide a username and password on visiting
a Web Site, a user would only need to provide authentication when a
security critical choice was being made. A user should not need to
'log in' to read a newspaper but additional confirmation is certainly
required when they decide to make a purchase or transfer funds from
their bank.
Hallam-Baker December 31, 2015 [Page 10]
Internet-Draft Modular Mathematical Mesh June 2015
2.3. Encrypted Email
Encrypted email was the original purpose for which the mesh
technology was developed under the name 'Prism-Proof email'. By
default, the mesh prototype will automatically configure certain
email clients for the use of encrypted mail. Once a client is
enabled, use of encryption is completely seamless and automatic
provided that an S/MIME capable email client is used.
While the large deployed base of S/MIME capable clients makes support
for this encryption format expedient, the mesh is designed to be
completely technology neutral. A public application profile for email
can specify the public encryption keys to be used and the encryption
formats they should be used with. If the user prefers OpenPGP, this
can be offered as an alternative. But rather than perpetuating
unnecessary format wars, the preferred situation would be for the
default to be to support both.
When using mesh enabled email security, a user may opt to make end-
to-end encryption their preferred option for an account. But doing so
will of course render any email messages unreadable on devices that
they have not yet connected to their profile. For this reason it is
suggested that early adopters of the email encryption capabilities
should consider creating a secondary account for their mesh email.
For example, alice@example.com might use mesh.alice@example.com to
receive encrypted messages.
The mesh provides a solution to two of the major challenges of end-
to-end encrypted email, distribution of public keys and management of
private keys. As described earlier, use of a public profile on the
cryptomesh solves the problem of public key distribution and use of
private profiles allows any device that has been connected to a
profile to access the current decryption key.
2.4. WiFi and Networking
One of the most tedious chores in administering a home network is
configuring devices to connect to one or more WiFi networks. And once
a device has been tediously configured, the work is likely to be
undone for the most trivial of reasons or for no reason at all.
Once a device is connected to a personal profile, it may be
authorized to use any WiFi network that is managed under that
profile. Alternatively the network owner may authorize a more limited
degree of network access. For example, a house guest might be
permitted to access a home WiFi network but only for a limited
period.
Hallam-Baker December 31, 2015 [Page 11]
Internet-Draft Modular Mathematical Mesh June 2015
2.5. Internet of Things
One of the primary motivations for designing the mesh was the
realization that with 50 IP addresses already assigned on the home
networks and a further 30 non-IP based network devices already
deployed, reducing network administration effort has become a
necessity, not a luxury. An automated home does not reduce effort or
stress if connected devices are perpetually failing or requiring
software upgrades.
Connecting an Internet of Things device such as a light bulb or a 3D
printer is little different in principle to connecting a computer or
a phone. The chief difference being that such devices may lack a
keyboard or a display of any kind and it may be desirable to limit
the degree of network access allowed. The coffee pot does not need to
run a file server or send thousands of emails a second, permitting
such access increases the risk of the device being compromised,
therefore the principle of least privilege demands that such a device
not be allowed unrestricted Internet access.
2.6. Developer Tools
Although the mesh is designed to support the needs of all Web users,
it is to be expected that early most adopters will be among the more
expert users.
The mesh provides a general purpose infrastructure on which any
application such as SSH or code signing can connect to cryptographic
credentials and resources as required.
3. Architecture
The foundational principle of the mesh is that the mesh cannot be
breached because the mesh does not offer any security guarantees.
* The mesh cannot suffer disclosure breach because all
confidential data stored in the mesh is encrypted end-to-end
using strong cryptographic algorithms and keys. This ensures
that the confidentiality of the data is protected unless the
encryption algorithms are broken or a breach occurs at the
end points where the private keys are stored.
* The mesh cannot suffer a permanent denial of service attack
as each mesh profile manager maintains a local copy of all
data stored in the mesh. Even if a mesh ceases operations
completely, a user may provision the same personal
profile(s) to a different mesh to quickly re-establish
service.
Hallam-Baker December 31, 2015 [Page 12]
Internet-Draft Modular Mathematical Mesh June 2015
* Recognizing the advances in computational power since the
original development of PKI in the mid-1990s, cryptographic
hygiene is encouraged through use of separate cryptographic
key material unless there are practical reasons to avoid
this approach.
A consequence of the last principle is that a Personal PKI for a user
with a large number of devices will have a large number of
cryptographic keys. In particular every device has its own keys for
authentication and key distribution and key material SHOULD NOT be
shared between application profiles. For applications such as email
encryption where it is desirable to be able to decrypt messages on
any connected device, a single encryption/decryption keypair MAY be
provisioned to multiple devices. In such circumstances, it is highly
desirable that such keys be rotated on a regular basis and in
particular when a device that has been provisioned with a current
decryption key is being disconnected from a profile.
3.1. Profiles
Three types of profile are currently defined:
Personal Profile
Each mesh user has one or more personal profiles to which
they may connect devices and applications as they choose.
Device Profile
Contains keys and settings for a device. A device profile
MAY be connected to multiple Personal Profiles at the same
time.
Application Profile
Contains keys and settings for a set of applications. An
application profile can only connect to one personal profile
at a time but MAY be transferred from one Personal Profile
to a successor.
The need for a profile to describe enterprise security configuration
data is acknowledged but not currently addressed.
3.1.1. Personal Profile
A personal profile consists of:
* A Personal PKI. [Public]
* A set of masked account identifiers. [Public, Signed]
* A set of Device Connection Entries. [Private, Signed]
Hallam-Baker December 31, 2015 [Page 13]
Internet-Draft Modular Mathematical Mesh June 2015
* A set of profiles describing applications enabled for that
account. [Private, Signed]
Items marked [Signed] are signed under a current Administration key
and Items marked [Private] are encrypted under the set of current
profile administration keys.
3.1.1.1. Personal PKI
Each Personal Profile contains a personal PKI hierarchy consisting
of:
Personal Master Signature Key (PMSK)
The root of trust for the Personal PKI, the public key of
the PMSK is presented as a self-signed X.509v3 certificate
with Certificate Signing use enabled. The PMSK is used to
sign certificates for the PMEK, POSK and PKEK keys.
Personal Master Escrow Key(s) (PMEK)
A Personal Profile MAY contain one or more PMEK keys to
enable escrow of private keys used for stored data. Note
that the presence and use of an escrow key are both
optional. A user MAY chose to create a profile without a
PMEK or choose not to use the escrow capability of a profile
that has a PMEK specified.
Personal Online Signature Key (POSK)
A Personal profile contains at least one POSK which is used
to sign device administration application keys.
The private key portions of the PMSK and PMEK are only ever used
during the initial configuration of the Personal PKI and in disaster
recovery situations. If a user loses access to a decryption key, the
PMEK may be used to recover and decrypt an escrowed copy. If a user
loses control over their POSK private key due to a device theft or
other compromise, the PMSK may be used to revoke it and possibly
establish a replacement.
Due to the importance of and infrequent need for access to the PMSK
and PMEK, profile managers MUST support and SHOULD encourage use of
the offline escrow mechanism described below for these private keys.
The key fingerprint of the PMSK is used as a unique identifier for
the corresponding profile.
Hallam-Baker December 31, 2015 [Page 14]
Internet-Draft Modular Mathematical Mesh June 2015
3.1.1.2. Device Connection Entry
A Device Connection Entry contains:
* The fingerprint of the Device Master Signature Key to which
it applies
* A set of application profiles connected to the personal
profile that the device is authorized to access
3.1.1.3. Application Profile
An Application Profile contains credential and network connection
data necessary to use a particular type of application such as
'email' or the password manager.
3.1.2. Device Profile
Each device that is connected to one or more Personal Profiles
publishes a device profile. A device may be connected to more than
one profile simultaneously. In this case the device MAY have separate
device profiles for each Personal Profile it is connected to or use a
common profile.
Device Master Signature Key (DSKK)
Used sign certificates for the DAK, DDK and DKEK and device
profiles.
Device Authentication Key (DAK)
Used to authenticate device requests.
Device Decryption Key (DDK)
Used to decrypt private portions of a device profile for
that device. For example, private keys, passwords etc.
3.2. Escrow
The mesh is a mechanism for managing cryptographic keys. Since the
ability to escrow private keys is an important function of a key
management infrastructure, the mesh provides an escrow mechanism. The
allows the mesh to enable applications involving stored data such as
whole disk encryption and end-to-end encrypted email while providing
safeguards against the risk of data loss should a device securing a
decryption key fail.
Although it is in principle possible to escrow any private key, the
use of an escrow mechanism dilutes the non-repudiation and forward
secrecy assurances that an application might assume. Thus the use of
key escrow is typically limited to:
Hallam-Baker December 31, 2015 [Page 15]
Internet-Draft Modular Mathematical Mesh June 2015
* Profile Master Keys (the PMSK and PMEKs)
* Decryption Keys used for encrypted stored data
A two tier escrow scheme is supported:
Online Escrow
The private key data is encrypted under a PMEK key described
in the Personal Profile.
Offline Escrow
The private key data is encrypted under a symmetric recovery
key. The recovery key is typically split using a key sharing
mechanism and the shares stored in a non-volatile media such
as ink and paper.
Note that in each case, the encrypted private key data is
typically stored in the mesh. It is only the means to
decrypt the escrow record that is online or offline.
3.2.1. Offline Escrow
Use of the offline escrow mechanism is typically limited to escrow of
the profile master keys (PMSK, PMEK) for which the online escrow
mechanism cannot be used.
Since the encrypted data will be stored as public data in the mesh,
the process used to generate the recovery key MUST ensure that it
contains at least as much ergodicity as the private key being
protected without disclosing information on the private key itself.
One means of ensuring that this is achieved is to generate a random
nonce value using the best available source and combine it with the
private key being escrowed by means of a secure cryptographic digest.
In order to minimize the amount of data required to recover escrowed
data, the object identifier of an offline escrow entry is the
fingerprint (i.e. a one way secure digest) of the recovery key.
Online Escrow
In the online escrow mechanism, the private key data is encrypted
under the PMEK of the associated profile.
The object identifier of an online escrow entry is formed by
encrypting the corresponding public key identifier under the PKEK of
the associated profile and taking the fingerprint.
Hallam-Baker December 31, 2015 [Page 16]
Internet-Draft Modular Mathematical Mesh June 2015
3.3. Identifiers
3.3.1. Object Identifiers
Every entry stored in the Mesh has an object identifier. The form of
the identifier is a Uniform Data Fingerprint (UDF). The input data
and precision are chosen to ensure that the object identifier is
globally unique with an acceptably high degree of assurance.
For the sake of convenience, the prototype mesh uses identifiers with
125 bit precision ensuring a negligible probability of two objects
being created with the same identifier until 2^50 (~10^15) entries
have been registered. A mesh gateway MAY chose a different level of
required precision or increase the level of precision required at any
time.
3.3.2. Account Identifier
An account identifier provides a user-friendly means of identifying a
mesh profile. A personal profile MAY have multiple account
identifiers but a MESH gateway MUST NOT permit the same account
identifier to be used to identify more than one profile at a time.
Account identifiers are assigned by a mesh gateway and entered using
the same form as an email address (i.e. @) where is the domain name
of the mesh gateway that assigned the identifier. This approach
avoids the need to ensure that account identifiers are globally
unique. To avoid enumeration attacks and similar forms of abuse, only
the fingerprint of the account identifier is exposed to the Mesh.
For example, Alice registers her personal profile at example.com
using the account identifiers 'alice' and 'bob'. This prevents Bob
from registering his profile at example.com as 'bob'. Alice then buys
a phone, to connect her phone to her Personal Profile, Alice enters
'alice@example.com' as her account identifier in the phone profile
manager. This allows the phone to retrieve Alice's personal profile
from the Mesh and present the fingerprint of the profile to Alice for
verification.
meshid = accountid ["@" domain]
accountid = username | fingerprint
3.3.3. Profile Identifier URI
The URI form of the profile identifier is a compact, machine
independent means of identifying a mesh profile. Since a personal
profile provides both a means of specifying an account
Hallam-Baker December 31, 2015 [Page 17]
Internet-Draft Modular Mathematical Mesh June 2015
For example, a server configuration file might grant access to Alice
as follows.
mmm:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice@cryptomesh.org {RWED}
Mesh profiles are identified using the mmm URI scheme as follows:
meshuri = "mmm:" fingerprint [ ":" meshid]
4. Application Profiles
Application profiles store information for use by a particular class
of application. A Personal Profile MAY contain more than one
application profile of a particular type and a single application
profile MAY describe the use of multiple protocols.
For example a user with multiple email accounts would require a
separate Email Application Profile for each account each of which
would typically specify connections for SUBMIT and IMAP/POP services
and public and private key sets for S/MIME and OpenPGP.
Application profiles are exchanged in JSON format. The schemas for
the individual application profiles will be described in a future
document.
4.1. Administration
The administration application profile is used to administer
connection of devices to a Personal Profile and enable the use of
particular application profiles on particular devices.
The public portion of the administration profile is the Personal
Profile itself. The private profile contains:
* Private Key of the POSK
4.2. Escrow
The escrow application profile is used to administer escrow of
private keys. The escrow profile contains:
* Escrow Public Key
* Escrow Identifier Encryption Key
4.3. Network Connection
A network application profile contains information for configuring a
network connection. This may include:
Hallam-Baker December 31, 2015 [Page 18]
Internet-Draft Modular Mathematical Mesh June 2015
* Connection data for one or more DNS services
* A scope for which the network connection is applied
4.4. Password Manager
A password manager application profile contains a list of password
entries each containing:
* The domain(s) for which the entry is to be used [required]
* Username [required]
* Password [required]
* HTTP strict security policy entry for the site [optional]
* HTTP Key Pining Security Policy for the site [optional]
* Acceptable authentication mechanisms [optional]
All the entries in the password manager are private with a decryption
blob for the device keys of each authorized device.
4.5. Authentication
While the password manager application is currently necessary it is
intended that this should be a transitional infrastructure rather
than a permanent one.
* The domain(s) for which the entry is to be used [optional]
* HTTP strict security policy entry for the site [optional]
* HTTP Key Pining Security Policy for the site [optional]
* Acceptable authentication mechanisms [optional]
In addition each device connected to an authentication profile has
the following device specific attributes:
* Authentication credential
4.6. Email
Under normal circumstances an email application profile enables use
of both S/MIME and OpenPGP security formats.
* Outbound mail server connection(s) (e.g. SUBMIT)
Hallam-Baker December 31, 2015 [Page 19]
Internet-Draft Modular Mathematical Mesh June 2015
* Inbound mail server connection(s) (e.g. POP3, IMAP4)
* Email encryption key (S/MIME) [Public]
* Email encryption key (OpenPGP) [Public]
* Email decryption key (S/MIME) [Private]
* Email decryption key (OpenPGP) [Private]
In addition each device connected to an email profile has the
following device specific attributes
* Email authentication credentials (OpenPGP)
* Email authentication credentials (S/MIME)
5. Mesh Services
The Mesh supports four separate protocols:
Mesh Gateway Service [Gateway]
Supports operations that create a permanent record in the
Gateway log. These include creation, update and management
of Profiles.
Mesh Gateway Request Service [Gateway]
Supports operations that will only create a permanent record
in the Gateway log if confirmed by a properly authorized
administration device.
Mesh Query Service [Gateway,Distribution]
Allows retrieval of information stored in the mesh without
creating a record in the Gateway log.
Mesh Replication Service [Gateway,Distribution]
Manages replication of closed Mesh logs between nodes.
The distinction between the two gateway services is that actions
performed using the Mesh Gateway Service will be eventually
replicated to every node in the mesh. The choice of Mesh node to
which a request was originally directed makes no difference after the
mesh has synchronized. In contrast, actions requested in the Mesh
Gateway Request Service are not permanently recorded or synchronized
to other nodes. It is therefore essential that all the steps
necessary to complete a transaction be directed to the same service.
The detailed description of the Mesh protocols will be described
separately in a future document.
Hallam-Baker December 31, 2015 [Page 20]
Internet-Draft Modular Mathematical Mesh June 2015
5.1. Mesh Log
Each mesh gateway node maintains an independent, append only log.
Each log is maintained as an incremental sequence of parts. Each part
is terminated by a signed record containing a digest over all the
entries in the current log and a chained digest over the digest of
the current log and the chained digest of the previous log.
Each mesh gateway performs a log rollover operation at frequent
intervals. The gateway begins a new log part which becomes the active
part in which all new transactions are recorded. The gateway then
calculates the terminal record for the previously active part and
writes it to the log to complete it.
Note that while this approach is simple and efficient for the mesh
gateway, it is not optimized for use by readers attempting to quickly
verify a single entry in the log. This may be revisited in future
versions of the Mesh if warranted.
5.2. Mesh Replication
At present the Mesh Replication Service has not been implemented.
Think NNTP in JSON with transaction records for each gateway node
being written to the equivalent of a newsgroup.
At present mesh services are presented as JSON services over HTTPS.
6. Requirements and Recommendations
Since the Mesh MAY be used to store keys for use with the highest
security levels supported by standards based cryptography and there
is no means of distinguishing high security keys from lesser keys,
all cryptographic operations employ the highest security level of the
available standards based cryptographic algorithms. This means use of
256 bit symmetric keys for encryption and MAC operations and 2048 bit
RSA. While longer RSA key sizes are available, the security advantage
they offer is not sufficient to justify use. A transition to use of
an ECC public key algorithm is preferred.
6.1. Requirements
A Mesh profile manager MUST support the following algorithms and data
formats:
* Encryption: AES-256
* Digest: SHA-2-512
* Public Key Encryption: RSA-2048
Hallam-Baker December 31, 2015 [Page 21]
Internet-Draft Modular Mathematical Mesh June 2015
* Public Key Signature: RSA-2048
* Public Key Agreement: DH-2048
* PKIX X.509v3 Certificate
* JSON (generate, read), JSON-B (read)
6.2. Recommendations
A Mesh profile manager SHOULD support the following algorithms and
data formats:
* Encryption: None
* Digest: SHA-3-512 [Once published by NIST]
* Public Key Encryption: CFRG-448 [When published]
* Public Key Signature: CFRG-448 [When published]
* JSON-B
7. Security Considerations
Currently the architecture of the Mesh is in a state of rapid change.
Users SHOULD not therefore rely on the security considerations set
out in this document without first checking to see if the instance of
the mesh they are connecting to follows the version of the mesh
protocols to which they refer.
7.1. Mesh Integrity
The state of the mesh is fully contained in the append-only logs
maintained by each mesh gateway. The mesh management protocols
require that each gateway sign their append-only log at regular
intervals and validate all data provided by other gateway nodes in
the mesh. Thus a mesh gateway node is the only party that can perform
a record insertion attack that another mesh node can be induced to
accept.
Further, the management of the logs provides complete transparency
for addition of entries by the gateway with continuous auditing by
every other mesh gateway. Thus it is impossible for one mesh gateway
node to defect unless every other gateway node in the mesh is willing
to collude in the deception.
Hallam-Baker December 31, 2015 [Page 22]
Internet-Draft Modular Mathematical Mesh June 2015
7.2. Mesh Data Confidentiality
The Mesh does not provide any confidentiality guarantees as all data
stored in the mesh is considered to be public. Thus the mesh cannot
be breached by definition but private data may be breached through
disclosure of the decryption keys or by use of faulty encryption
algorithm.
7.3. Disclosure of Private Key
Disclosure of the private keys used to secure private data may result
in disclosure of confidential data. Unencrypted private keys are only
kept at end point devices. Private key disclosure is bad, avoid.
Trustworthy computing features preventing/making it difficult to
extract keys from a device are highly desirable.
7.4. Denial of Service
Denial of Service attacks are an important threat that is not
currently addressed in the prototype implementation.
The use of a combination of proof of work and lightweight
authentication approaches is anticipated to address this
consideration.
7.5. Traffic Analysis
Mesh transactions SHOULD be considered to be vulnerable to traffic
analysis unless a security analysis of a specific mesh instance has
been performed to provide evidence to the contrary.
7.6. Covert Channels
The mesh provides a medium for exchange of end-to-end encrypted data.
Since the mesh nodes have no means of determining the contents of
profile entries, there is no means of restricting use to those
approved by the operators. The mesh thus represents a ubiquitous and
pervasive covert channel.
While this situation is not necessarily to be considered a security
concern for mesh operators, the resources consumed by such operations
may be a concern. Since all profiles entered into the mesh are
permanently recorded and replicated to every mesh node, use of the
mesh for purposes such as covert transfer of streaming video are
likely to be a concern.
The use of resource limiting strategies such as CAPTCHAs, profile
size limits and limits on the number of updates individual users are
permitted to make in a short time period SHOULD therefore be
considered.
Hallam-Baker December 31, 2015 [Page 23]
Internet-Draft Modular Mathematical Mesh June 2015
7.7. Data Loss
The risk of data loss is mitigated through a combination of local
retention, use of the mesh to provide data persistence and key
escrow.
7.8. User Capture
User capture is the situation where a user of a software service is
unable to change software service providers due to unacceptably high
switching costs. This puts the user of the service at a severe
disadvantage to the provider. While achieving such a circumstance is
frequently the objective of many a business plan, such plans almost
invariably fail.
Local capture of Mesh data and the planned mesh replication
infrastructure ensure that switching costs for users are never
prohibitive. Thus user capture is avoided.
8. IANA Requirements
8.1. Registration of mmm URI Scheme (provisional)
TBS
8.2. Registration of application/mesh Content Types
TBS
9. Acknowledgements
The mesh builds on much prior art in the field.
As described above, the mesh deployment model consciously follows the
pattern set by the World Wide Web which was in turn based on
observation of the success of earlier innovations such as the micro-
computer. The purpose for which the Web was designed was to make the
universe of information accessible, the killer application for the
Web at CERN was the ability to access the telephone directory online.
The use of append-only logs with chained cryptographic digests was
originally proposed by Harber and Stornetta but only popularized
through the use in the BitCoin blockchain and the Certificate
Transparency log after the patent protection expired.
The idea of using X.509 to establish a personal PKI hierarchy arose
from discussions with Sir Tim Berners-Lee at CERN in 1994. The use of
fingerprints of public keys was introduced by Phil Zimmerman in PGP.
Hallam-Baker December 31, 2015 [Page 24]
Internet-Draft Modular Mathematical Mesh June 2015
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker December 31, 2015 [Page 25]
