idnits 2.17.1 draft-hallambaker-mesh-architecture-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 25 October 2021 5 Expires: 28 April 2022 7 Mathematical Mesh 3.0 Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-19 10 Abstract 12 The Mathematical Mesh is a Threshold Key Infrastructure that makes 13 computers easier to use by making them more secure. Application of 14 threshold cryptography to key generation and use enables users to 15 make use of public key cryptography across multiple devices with 16 minimal impact on the user experience. 18 This document provides an overview of the Mesh data structures, 19 protocols and examples of its use. 21 [Note to Readers] Discussion of this draft takes place on the 22 MATHMESH mailing list (mathmesh@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 25 This document is also available online at 26 http://mathmesh.com/Documents/draft-hallambaker-mesh- 27 architecture.html. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 28 April 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Related Specifications . . . . . . . . . . . . . . . . . 7 62 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 64 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 7 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. The Device Management Challenge . . . . . . . . . . . . . 10 67 3.2. Exchange of trusted credentials. . . . . . . . . . . . . 11 68 3.3. Application configuration management . . . . . . . . . . 11 69 3.4. Mesh Service Provider . . . . . . . . . . . . . . . . . . 12 70 3.5. The Mesh as platform . . . . . . . . . . . . . . . . . . 12 71 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.7. Enterprise Deployment . . . . . . . . . . . . . . . . . . 13 73 4. User Experience . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Creating a Mesh Account . . . . . . . . . . . . . . . . . 13 75 4.1.1. Encrypting and Decrypting files. . . . . . . . . . . 15 76 4.1.2. Catalogs . . . . . . . . . . . . . . . . . . . . . . 16 77 4.2. Adding devices . . . . . . . . . . . . . . . . . . . . . 16 78 4.2.1. Direct Connection . . . . . . . . . . . . . . . . . . 18 79 4.2.2. PIN Connection . . . . . . . . . . . . . . . . . . . 18 80 4.2.3. Making use of the new device . . . . . . . . . . . . 20 81 4.2.4. Applications . . . . . . . . . . . . . . . . . . . . 20 82 4.2.5. Threshold Key Devices . . . . . . . . . . . . . . . . 21 83 4.3. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 22 84 4.3.1. Contact exchange . . . . . . . . . . . . . . . . . . 23 85 4.3.2. Confirmation service . . . . . . . . . . . . . . . . 26 86 4.4. Encryption Groups . . . . . . . . . . . . . . . . . . . . 27 87 4.5. Deleting Devices . . . . . . . . . . . . . . . . . . . . 29 88 4.6. Escrow and Recovery . . . . . . . . . . . . . . . . . . . 30 89 4.7. Future Directions . . . . . . . . . . . . . . . . . . . . 31 90 4.7.1. Device Disconnection . . . . . . . . . . . . . . . . 31 91 4.7.2. Service Transition . . . . . . . . . . . . . . . . . 31 92 4.7.3. Threshold User Account . . . . . . . . . . . . . . . 32 93 4.7.4. Threshold Group Administration . . . . . . . . . . . 32 94 4.7.5. Synchronous Messaging . . . . . . . . . . . . . . . . 33 95 4.7.6. Social Media . . . . . . . . . . . . . . . . . . . . 33 96 5. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 33 97 5.1. Best Practice by Default . . . . . . . . . . . . . . . . 34 98 5.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 35 99 5.3. Threshold Decryption . . . . . . . . . . . . . . . . . . 35 100 5.4. Threshold Key Generation . . . . . . . . . . . . . . . . 36 101 5.5. Threshold Signature . . . . . . . . . . . . . . . . . . . 36 102 5.6. Data At Rest Encryption . . . . . . . . . . . . . . . . . 37 103 5.6.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 37 104 5.6.2. Dare Sequence . . . . . . . . . . . . . . . . . . . . 37 105 5.7. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 38 106 5.7.1. Friendly Names . . . . . . . . . . . . . . . . . . . 39 107 5.7.2. Encrypted Authenticated Resource Locators . . . . . . 39 108 5.7.3. Secure Internet Names . . . . . . . . . . . . . . . . 40 109 5.8. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 40 110 6. Mesh Architecture . . . . . . . . . . . . . . . . . . . . . . 42 111 6.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 42 112 6.1.1. Account . . . . . . . . . . . . . . . . . . . . . . . 43 113 6.1.2. Device . . . . . . . . . . . . . . . . . . . . . . . 44 114 6.1.3. Service . . . . . . . . . . . . . . . . . . . . . . . 45 115 6.2. Stores . . . . . . . . . . . . . . . . . . . . . . . . . 46 116 6.2.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 46 117 6.2.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 47 118 6.3. Mesh Service Protocol . . . . . . . . . . . . . . . . . . 48 119 6.3.1. Protocol Interactions . . . . . . . . . . . . . . . . 49 120 6.4. The Access Catalog . . . . . . . . . . . . . . . . . . . 49 121 6.5. Mesh Messaging Protocol . . . . . . . . . . . . . . . . . 50 122 6.6. Using the Mesh with Applications . . . . . . . . . . . . 52 123 6.6.1. Future Applications . . . . . . . . . . . . . . . . . 53 124 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 125 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 126 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 127 10. Normative References . . . . . . . . . . . . . . . . . . . . 54 128 11. Informative References . . . . . . . . . . . . . . . . . . . 56 130 1. Introduction 132 The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure (TKI) 133 that uses cryptography to make computers easier to use. This 134 document describes version 3.0 of the Mesh architecture and 135 protocols. 137 In 1977, Public Key cryptography laid out a powerful proposition: If 138 Alice and Bob have private keys on their devices and each knows the 139 public key of the other, Alice and Bob can communicate with 140 confidentiality and integrity. The realization of this proposition 141 at Internet scale was vested in a technology called Public Key 142 Infrastructure (PKI) whose principal function is to provide a 143 trustworthy means by which Alice and Bob can discover each other's 144 public key. 146 Yet despite the power of PKI, Internet security remains a work in 147 progress. While PKI has proved an effective means of authenticating 148 services to users, attempts to apply PKI to the equally important 149 task of authenticating users to services and securing data at rest 150 have been confined to the margins. One critical reason for that 151 failure is that _Public_ Key Infrastructure has only provided 152 effective tools for managing _public_ keys. If we are to achieve 153 comprehensive Internet security, we must provide every user with the 154 ability to manage _private_ keys across their devices with zero 155 effort on their part. 157 Threshold cryptography is a sub-field of public key cryptography that 158 defines operations on cryptographic keys, including operations on 159 private keys. Threshold cryptography allows Key generation and key 160 use operations may be split between multiple devices. These tools 161 make zero effort management of private keys practical. 163 The Mesh is a TKI that addresses the three principal concerns that 164 have proved obstacles to the use of end-to-end security in computer 165 applications: 167 * Device management. 169 * Exchange of trusted credentials. 171 * Application configuration management. 173 The infrastructure developed to address these original motivating 174 concerns can be used to facilitate deployment and use of existing 175 security protocols (OpenPGP, S/MIME, SSH) and as a platform for 176 building end-to-end secure network applications. Current Mesh 177 applications include: 179 * Multi-factor authentication and confirmation 181 * Credential management 183 * Bookmark/Citation management 185 * Task and workflow management 187 A core principle of the design of the Mesh is _autonomy_. That is 188 each user has full control over their digital environment and is 189 their own source of authority. They may choose to delegate that 190 authority to another to act on their behalf (i.e. a Trusted Third 191 Party) and they may choose to surrender parts of that authority to 192 others (e.g. an employer) without surrendering their autonomy. 193 Delegation of authority is always for limited times and limited 194 purposes. 196 Thus, from the user's point of view, the Mesh is divided into two 197 parts: The part of the Mesh that belongs to them and everything else. 198 As with the Internet, which is a network of networks, a Mesh of 199 Meshes has certain properties that are similar to those of its 200 constituent parts and some that are quite different. 202 This document is not normative. It provides an overview of the Mesh 203 comprising a description of the architecture, and a discussion of 204 typical use cases and requirements. The remainder of the document 205 series provides a summary of the principal components of the Mesh 206 architecture and their relationship to each other. 208 Normative descriptions of the individual Mesh encodings, data 209 structures and protocols are provided in separate documents 210 addressing each component in turn. 212 The currently available Mesh document series comprises: 214 I. Architecture (This document.) Provides an overview of the Mesh 215 as a system and the relationship between its constituent parts. 217 II. Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. Describe 218 s the UDF format used to represent cryptographic nonces, keys and 219 content digests in the Mesh and the use of Encrypted Authenticated 220 Resource Locators (EARLs) and Strong Internet Names (SINs) that 221 build on the UDF platform. 223 III. Data at Rest Encryption [draft-hallambaker-mesh-dare]. Describ 224 es the cryptographic message and append-only sequence formats used 225 in Mesh applications and the Mesh Service protocol. 227 IV. Schema Reference [draft-hallambaker-mesh-schema]. Describes the 228 syntax and semantics of Mesh Profiles, Catalog and Spool Entries 229 and Mesh Messages and their use in Mesh Applications. 231 V. Protocol Reference [draft-hallambaker-mesh-protocol]. Describes 232 the Mesh Service Protocol. 234 VI. Reliable User Datagram [draft-hallambaker-mesh-rud]. Describes 235 the Mesh presentation and transport layer. 237 VII Mesh Callsign Service [draft-hallambaker-mesh-callsign]. Describ 238 es the Mesh Callsign Service that supports mapping of Mesh 239 callsigns to the corresponding Mesh Service Provider. 241 VIII. Security Considerations [draft-hallambaker-mesh-security] Des 242 cribes the recommended and required algorithm suites and the 243 security considerations for the Mesh protocol suite. 245 IX. Cryptographic Algorithms [draft-hallambaker-mesh-security] Desc 246 ribes the cryptographic algorithm suites used in the Mesh and the 247 implementation of Multi-Party Encryption and Multi-Party Key 248 Generation used in the Mesh. 250 The following documents describe technologies that are used in the 251 Mesh but do not form part of the Mesh specification suite: 253 X. The Trust Mesh [draft-hallambaker-mesh-trust]. Describes the 254 social work factor metric used to evaluate the effectiveness of 255 different approaches to exchange of credentials between users and 256 organizations in various contexts and argues for a hybrid approach 257 taking advantage of direct trust, Web of Trust and Trusted Third 258 Party models to provide introductions. 260 JSON-BCD Encoding [draft-hallambaker-jsonbcd]. Describes extensions 261 to the JSON serialization format to allow direct encoding of 262 binary data (JSON-B), compressed encoding (JSON-C) and extended 263 binary data encoding (JSON-D). Each of these encodings is a 264 superset of the previous one so that JSON-B is a superset of JSON, 265 JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C. 267 DNS Web Service Discovery 268 [draft-hallambaker-web-service-discovery]. Describes the means by 269 which prefixed DNS SRV and TXT records are used to perform 270 discovery of Web Services. 272 Threshold Modes in Elliptic Curves [draft-hallambaker-threshold]. De 273 scribes threshold key generation and key agreement operations for 274 the Ed25519, Ed448, X25519 and X448 elliptic curves. 276 The following documents describe aspects of the Mesh Reference 277 implementation: 279 Mesh Developer [draft-hallambaker-mesh-developer]. Describes the 280 reference code distribution license terms, implementation status 281 and currently supported functions. 283 Mesh Platform [draft-hallambaker-mesh-platform]. Describes how 284 platform specific functionality such as secure key storage and 285 trustworthy computing features are employed in the Mesh. 287 2. Definitions 289 This section presents the related specifications and standards on 290 which the Mesh is built, the terms that are used as terms of art 291 within the Mesh protocols and applications and the terms used as 292 requirements language. 294 2.1. Related Specifications 296 Besides the documents that form the Mesh core, the Mesh makes use of 297 many existing Internet standards, including: 299 Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic 300 algorithms for Mesh implementations are specified in 301 [draft-hallambaker-mesh-cryptography]. 303 In addition, Mesh Devices used to administer non-Mesh applications 304 require support for the cryptographic algorithm suites relevant to 305 the application. 307 Transport All Mesh Services make use of multiple layers of security. 308 Protection against traffic analysis and metadata attacks are 309 provided by use of Transport Layer Security [RFC5246]. At 310 present, the HTTP/1.1 [RFC7231] protocol is used to provide 311 framing of transaction messages. 313 Encoding All Mesh protocols and data structures are expressed in the 314 JSON data model and all Mesh applications accept data in standard 315 JSON encoding [RFC7159]. The JOSE Signature [RFC7515] and 316 Encryption [RFC7516] standards are used as the basis for object 317 signing and encryption. 319 2.2. Defined Terms 321 TBS 323 2.3. Requirements Language 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 327 document are to be interpreted as described in RFC 2119 [RFC2119]. 329 2.4. Implementation Status 331 The implementation status of the reference code base is described in 332 the companion document [draft-hallambaker-mesh-developer]. 334 The examples in this document were created on 10/21/2021 5:47:09 PM. 335 Out of 174 examples, 47 failed. 337 3. Requirements 339 The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure that 340 uses cryptography to make computers easier to use. 342 For several decades, it has been widely noted that most users are 343 either unwilling or unable to make even the slightest efforts to 344 protect their security, still less those of other parties. Yet 345 despite this observation being widespread, the efforts of the IT 346 security community have largely focused on changing this user 347 behavior rather that designing applications that respect it. Real 348 users have real work to do and have neither the time nor the 349 inclination to use tools that will negatively impact their 350 performance. 352 The Mesh is based on the principle that if the Internet is to be 353 secure, secure use of applications must become effortless. Rather 354 than beginning the design process by imagining all the possible modes 355 of attack and working out how to address these as best as possible 356 with least inconvenience to the user, we must reverse the question 357 and ask how much security can be provided without requiring any 358 effort whatsoever from the user. This principle is called*Zero 359 Effort Security*. 361 Today's technology requires users to put their trust in an endless 362 variety of devices, software and services they cannot fully 363 understand let alone control. Even the humble television of the 20th 364 century has been replaced by a 'smart' TV with 15 million lines of 365 code whose undeclared capabilities may well include placing the room 366 in which it is placed under continuous audio and video surveillance. 368 Every technology deployment by necessity requires some degree of 369 trust on the owner/user's part. But this trust should not compromise 370 the user's autonomy. Delegation of trust should be limited and 371 subject to accountability. If manufacturers continue to fail in this 372 regard, they risk a backlash in which users seek to restore their 373 rights through litigation, legislation or worst of all, simply not 374 buying more technology that they have learned to distrust through 375 their own experience. 377 The Mesh is based on the principle of radical distrust, that is, if a 378 party is capable of defecting, we assume that they will. As the 379 Russian proverb goes: ???????, ?? ????????: trust, but verify. 381 In the 1990s, the suggestion that 'hackers' might seek to make 382 financial gains from their activities was denounced as 'fear- 383 mongering'. The suggestion that email or anonymous currencies might 384 be abused received a similar response. Today malware, ransomware and 385 spam have become so ubiquitous that they are no longer news unless 386 the circumstances are particularly egregious. In 1949, Edward A. 387 Murphy Jr. proposed his now eponymous law which states, 'Anything 388 that can go wrong will go wrong'. We must now apply a similar 389 principle to Internet security: 'Anything that can be made to go 390 wrong is already being made to go wrong and will only get worse until 391 something is done to stop it.' 393 We must dispense with the notion that it is improper or impolite to 394 question the good faith of technology suppliers of any kind whether 395 they be manufacturers, service providers, software authors or 396 reviewers. Modern supply chains are complex, typically involving 397 hundreds if not thousands of potential points of deliberate or 398 accidental compromise. The technology provider who relies on the 399 presumption of good faith on their part risks serious damage to their 400 reputation when others assert that a capability added to their 401 product may have malign uses. 403 Radical distrust means that we apply the principles of least 404 principle and accountability at every level to the design of the 405 Mesh: 407 * Cryptographic keys installed in a product during manufacture are 408 only used for the limited purpose of putting that device under 409 control of the user. 411 * Cryptographic keys and assertions related to management of devices 412 are only visible to the user they belong to and are never exposed 413 to external parties. 415 * Mesh Accounts belong to and are under control of the user they 416 belong to and not the Mesh Service provider which the user can 417 change at will with minimal inconvenience. 419 * Mesh Services do not have access to the plaintext of any Mesh 420 Messages or Mesh Catalog data except for the threshold catalog 421 used by the service as the source of access control policy. 423 * All Mesh Messages are subject to access control by both the 424 inbound and outbound Mesh Service to mitigate messaging abuse. 426 Security is risk management and not the elimination of every possible 427 risk. Radical distrust means that we raise the bar for attackers to 428 the point where for most attackers the risk is greater than the 429 reward. It does not demand that we immediately address every issue 430 with perfection or delay deployment of technologies that are capable 431 of controlling _many_ risks until we have achieved the control of 432 _every_ risk. 434 In addition to distrusting technology providers the Mesh Architecture 435 allows the user to limit the degree of trust they place in 436 themselves. In the real world, devices are lost or stolen, passwords 437 and activation codes are forgotten, natural or man-made catastrophes 438 cause property and data to be lost. The Mesh permits but does not 439 require use of escrow techniques that allow recovery from such 440 situations. 442 3.1. The Device Management Challenge 444 Existing PKIs were developed in an era when the 'personal computer' 445 was still coming into being. Only a small number of people owned a 446 computer and an even smaller number owned more than one. In these 447 circumstances, it arguably sufficed to provision a user with a single 448 key pair on the single device they were likely to use. Creating keys 449 was a time-consuming business that might take several minutes, an 450 architecture in which an end user might create and use hundreds of 451 key pairs was beyond the capabilities of the available hardware. 453 Today, computers are ubiquitous and a typical home in the developed 454 world contains several hundred of which a dozen or more may have some 455 form of network access. The modern consumer faces a problem of 456 device management that is considerably more complex than the IT 457 administrator of a small business might have faced in the 1990s but 458 without any of the network management tools such an administrator 459 would expect to have available. 461 One important consequence of the proliferation of devices is that 462 end-to-end security is no longer sufficient. To be acceptable to 463 users, a system must be ends-to-ends secure. That is, a user must be 464 able to read their encrypted email message on their laptop, tablet, 465 phone, or watch with exactly the same ease of use as if the mail were 466 unencrypted. A cryptographic security control that impedes the user 467 is a control that is not going to be used. 469 Each personal Mesh contains a device catalog in which the 470 cryptographic credentials and device specific application 471 configurations for each connected device are stored. A device 472 granted administration rights can use the device catalog to configure 473 each connected device with the precise cryptographic credentials it 474 needs to perform its functions. 476 3.2. Exchange of trusted credentials. 478 One of the most challenging, certainly the most contentious issues in 479 PKI is the means by which cryptographic credentials are published and 480 validated. Here there are two different challenges. 482 Developing an infrastructure that provides a mapping to a 483 cryptographic key from a name that serves no other purpose than 484 identifying the key is relatively easy. Developing an infrastructure 485 that maps existing names with semantics that are already established 486 is considerably harder. 488 The Mesh does not attempt to impose criteria for accepting 489 credentials as valid as no such set of criteria can be comprehensive. 490 Rather, the Mesh provides an internal trust infrastructure that makes 491 use of a _direct trust_ model similar to that of PGP fingerprints to 492 which external names may be mapped using whatever validation criteria 493 users consider are appropriate to the purpose for which they intend 494 to use them. 496 The principles of providing extended trust management in the Mesh are 497 further described in [draft-hallambaker-mesh-trust]. 499 3.3. Application configuration management 501 Configuration of cryptographic applications is typically an 502 afterthought (or worse). Configuration of one popular mail user 503 agent to use S/MIME security requires 17 steps to be performed using 504 four separate application programs. And since S/MIME certificates 505 expire, the user is required to repeat these steps every few years. 506 Contrary to the public claims made by one major software vendor it is 507 not necessary to perform 'usability testing' to recognize abject 508 stupidity. 510 Rather than writing down configuration steps and giving them to the 511 user, we should turn them into code and give them to a machine. 512 Users should never be required to do the work of the machine. Nor 513 should any programmer be allowed to insult the user by casting their 514 effort aside and requiring it to be re-entered. 516 While most computer professionals who are required to do such tasks 517 on a regular basis will create a tool for the purpose, most users do 518 not have that option. And of those who do write their own tools, 519 only a few have the time and the knowledge to do the job without 520 introducing security vulnerabilities. 522 3.4. Mesh Service Provider 524 As might be expected of a Key _Infrastructure_, use of the Mesh 525 typically requires the use of an online service to provide an always 526 present point of service through which devices which are not 527 permanently connected can exchange messages. This online service is 528 called a *Mesh Service Provider* (*MSP*). 530 An MSP performs similar functions to an SMTP mail provider but with 531 one important distinction: MSPs do not issue or own Mesh accounts. A 532 Mesh account is always created by and belongs to its user who can 533 change their MSP at any time without changing their account. 534 Further, a user MAY choose to act as their own MSP. 536 3.5. The Mesh as platform 538 Meeting the core objectives of the Mesh required new naming, 539 communication and cryptographic capabilities provided to be 540 developed. These capabilities may in turn be used to develop new 541 end-to-end secure applications. 543 For example, the Mesh Catalogs used to maintain collections of device 544 descriptions, bookmarks, credentials, etc. might be used in an 545 electronic records infrastructure to maintain chain of custody of 546 digital evidence. 548 3.6. Security 550 The Mesh is designed to provide the greatest practical level of 551 security that does not detract from the user experience. The usual 552 CIA triad is considered: 554 Confidentiality The confidentiality of user content should be 555 protected at all times and against all unauthorized parties 556 including their MSP. 558 Reasonable efforts should be taken to protect user data against 559 traffic analysis and metadata attacks. It is not necessary to 560 consider disclosure of this information to MSPs. Metadata must be 561 shielded from external parties but controls to prevent traffic 562 analysis may be left to implementers. 564 Integrity The design should consider unauthorized modification of 565 data to be at least as serious as disclosure. 567 Availability The design should consider loss of data likely to be at 568 least as serious as disclosure. 570 In addition to protecting the user's data, the Mesh is designed to 571 protect the user's autonomy. While the use of any electronic device 572 or service entails a degree of trust, the user should have the right 573 to decide which devices and which service providers to trust and to 574 have the practical ability to revoke that trust at any time they 575 choose. 577 3.7. Enterprise Deployment 579 Development of PKI has traditionally focused on the needs of large 580 enterprises. The Mesh is focused on the individual user. While this 581 change of focus is in part a recognition of the need to reverse the 582 traditional bias, it is also a recognition of the fact that we must 583 understand the needs of the individual user before attempting to 584 understand the additional needs of an enterprise IT department 585 serving a large number of users. 587 4. User Experience 589 This section describes the Mesh in use. These _use cases_ described 590 here are re-visited in the companion Mesh Schema Reference 591 [draft-hallambaker-mesh-schema] and Mesh Protocol Reference 592 [draft-hallambaker-mesh-protocol] with further details and additional 593 examples. 595 For clarity and compactness of exposition, these use cases are 596 illustrated using the command line tool _meshman_, a tool that makes 597 the cryptographic operations explicit. This does not represent the 598 ideal user experience in which Zero-effort security is achieved. 599 Such a user experience requires that the Mesh operations be 600 seamlessly integrated into the user's applications so that instead of 601 using the meshman tool to encrypt or decrypt document, the word 602 processor application itself would be extended to read and write 603 documents encrypted in the DARE format. 605 4.1. Creating a Mesh Account 607 From the user's perspective, their personal Mesh consists of a 608 collection of devices that communicate seamlessly and securely 609 through a Mesh account serviced by an MSP. 611 (Artwork only available as svg: No external link available, see 612 draft-hallambaker-mesh-architecture-19.html for artwork.) 614 Figure 1: Alice's personal Mesh. 616 As with an email service provider, the user is only likely to be 617 aware of their interactions with their MSP in the case of a service 618 interruption. As far as the user is concerned the data is replicated 619 across their devices automatically unless there is a problem. 621 While the term 'account' is used because it is the term a user is 622 familiar with that most closely describes its functions, Mesh 623 accounts are different from traditional Internet accounts in one 624 important respect: In order to realize the principle of 'autonomy', 625 Mesh accounts are created by and _belong to_ the user and not the 626 service provider. Should a serious problem occur, a user may opt to 627 change their MSP. But unlike a changing an SMTP email provider, this 628 change is made seamless and cost free. 630 Another important difference between the Mesh and SMTP is that all 631 Mesh data is encrypted end to end. The MSP does not have access to 632 any user content and does not have access to any user meta-data 633 except that which is strictly necessary to service the account. 635 The only Mesh catalogs associated with a Mesh account that can be 636 read by an MSP are the Access Catalog which serves as the basis for 637 specifying and enforcing access control policy on the resources 638 associated with the account and the Publications Catalog which is an 639 index of encrypted data published through the account. 641 To create a Mesh account, the user need only specify the account name 642 and the initial MSP: 644 The user specifies the initial account address to be used 645 (alice@example.com). Use of this address is of course dependent on 646 authorization by the Mesh Service Provider (example.com) and is 647 likely to require authentication and possibly payment. 649 Alice> account create alice@example.com 650 Account=alice@example.com 651 UDF=MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 653 The command returns the value of Alice's Mesh Account fingerprint . 654 This value is used as a unique identifier that is cryptographically 655 bound to the signature key used to authenticate the account profile. 657 Note that the user does not specify the cryptographic algorithms to 658 use. Choice of cryptographic algorithm is primarily the concern of 659 the protocol designer, not the user. The only circumstance in which 660 users would normally be involved in algorithm selection is when there 661 is a transition in progress from one algorithm suite to another. 663 4.1.1. Encrypting and Decrypting files. 665 Having created an account, Alice can use it to encrypt files and 666 decrypt them on the same machine. 668 Alice encrypts the text file plaintext.txt to create an encrypted 669 version readable only by Alice: 671 Alice> type plaintext.txt 672 This is a test 673 Alice> dare encode plaintext.txt ciphertext.dare /encrypt ^ 674 alice@example.com 675 Alice> dare verify ciphertext.dare 676 File: ciphertext.dare 677 Bytes: 16 678 Encryption Algorithm: A256CBC 679 Recipient: MASN-NAYB-IY7F-JCFZ-RFWV-UIT4-MSEZ 680 Digest Algorithm: S512 681 Payload Digest: D7CA69323707D3464C98426EBFBB3F69CDBEF6CB11B1B3F5F 682 3B97C4C847A46B52B743ACAD559EECBD0139FF575E81AFE0BDA8296569A62008D8BD5 683 3FF6FA5374 685 Alice can recover the file at any time using the decryption command: 687 Alice> dare decode ciphertext.dare plaintext1.txt 688 Alice> type plaintext1.txt 689 This is a test 691 Although the encrypted file can be accessed by Alice with precisely 692 the same ease as the plaintext version, the contents of the encrypted 693 file are not readable by any other user of the machine unless Alice 694 explicitly grants access. The encrypted file may be stored on a 695 shared drive, cloud file system or removable storage without 696 disclosing the contents. 698 While encrypting and decrypting files using a tool provides the 699 desired functionality, it does not meet our objectives for usability. 700 These capabilities should be integrated into applications or the 701 platform itself. 703 4.1.2. Catalogs 705 Every Mesh account is created with a set of catalogs and spools. For 706 example, the bookmarks catalog maintains a list of the user's Web 707 bookmarks. The credentials catalog maintains a list of the user's 708 usernames and passwords for the various network services they use. 709 As with the file encryption example, these capabilities are clearly 710 going to be most effective when incorporated into the user's 711 applications, (i.e. their Web browser). 713 Alice adds the username and password she uses to access her weather 714 service account to her credentials catalog: 716 Alice> password add ftp.example.com alice1 password 717 alice1@ftp.example.com = [password] 719 Alice> password add www.example.com alice@example.com newpassword 720 alice@example.com@www.example.com = [newpassword] 722 As with all Mesh Catalogs, the catalog data is encrypted and cannot 723 be accessed by any unauthorized party including the Mesh Service 724 Provider. 726 If needed, she can retrieve the credentials from the catalog by 727 specifying the network resource to which access is required: 729 Alice> password get ftp.example.com 730 alice1@ftp.example.com = [password] 732 This capability provides a means of preventing one of the most common 733 causes of enterprise password breach in which a system administrator 734 encodes the access credentials for a service into a script used to 735 access the service. A script containing a command to extract the 736 credentials from a Mesh catalog will only work for a user authorized 737 to access the credentials in the Mesh. 739 4.2. Adding devices 741 Computers have become ubiquitous and inexpensive. Most people living 742 in affluent countries interact with several dozen computer systems 743 every day. Every household appliance from the television to the 744 coffee pot has become or is in the process of becoming a computer. 745 It is this circumstance that has exposed the critical flaw in 746 traditional PKI: The lack of practical means of managing private keys 747 across multiple devices. 749 The Mesh allows users to connect all their devices together so that 750 they may be considered part of a single entity whose component parts 751 communicate and interact seamlessly and securely. 753 Although any type of network capable device may be connected to a 754 Mesh profile, some devices are better suited for use with certain 755 applications than others. Connecting an oven to a Mesh profile could 756 allow it to be controlled through entries to the user's recipe and 757 calendar catalogs and alert the user when the meal is ready but 758 attempting to use it to read emails or manage Mesh profiles. The 759 Mesh allows the principle of least privilege when connecting a device 760 granting precisely the set of capabilities required to perform its 761 intended function. 763 Multiple connection mechanisms are specified, each of which provides 764 strong mutual authentication. In each case, the connection request 765 must be approved by a device provisioned with the Mesh administration 766 privilege: 768 Direct The connection request is initiated on the device being 769 requested and approved on the administration device. 770 Authentication of the connection request is performed by comparing 771 witness values presented on the connecting device and the 772 administration device. 774 PIN A PIN code is generated on an administration device and passed 775 to the connecting device out of band. The connecting device 776 provides proof of knowledge of this PIN code when making the 777 connection request allowing an administration device to approve 778 the request automatically without further user interaction. 780 Dynamic QR This connection mechanism is a variation of the PIN 781 connection mechanism in which administration device presents the 782 PIN code value to the connecting device in the form of a QR code. 783 This allows a connecting device with a camera to connect with 784 minimal user effort. 786 Static QR This connection method is designed to support connection 787 of constrained IoT devices that lack a camera or display 788 capability but requires that the device be pre-provisioned during 789 manufacture or distribution. 791 An administration device equipped with a camera reads a static QR 792 code printed on the device that provides the information used to 793 enable the administration device to establish a local network 794 connection (e.g. WiFi, Bluetooth, strobe, IR) that can be used to 795 complete the connection. 797 These connection mechanisms are described in detail in the Mesh 798 Protocol Reference [draft-hallambaker-mesh-protocol]. 800 4.2.1. Direct Connection 802 For example, Alice connects a second device using the direct 803 connection mechanism: 805 The connection request is initiated on the device being connected: 807 Alice2> device request alice@example.com 808 Device UDF = MBAY-U7J2-UC3W-OMBO-RKNN-ZUTA-LDJD 809 Witness value = 4GPE-3XFD-4LT5-RUZY-XA3J-BAXD-HNP7 811 Using her administration device, Alice gets a list of pending 812 requests. Seeing that there is a pending request matching the 813 witness value presented by the device, Alice accepts the request, 814 granting the new device the messaging and web roles: 816 Alice> device pending 817 MessageID: 4GPE-3XFD-4LT5-RUZY-XA3J-BAXD-HNP7 818 Connection Request:: 819 MessageID: 4GPE-3XFD-4LT5-RUZY-XA3J-BAXD-HNP7 820 To: From: 821 Device: MBAY-U7J2-UC3W-OMBO-RKNN-ZUTA-LDJD 822 Witness: 4GPE-3XFD-4LT5-RUZY-XA3J-BAXD-HNP7 823 Alice> device accept 4GPE-3XFD-4LT5-RUZY-XA3J-BAXD-HNP7 /message /web 825 Alice can now synchronize her newly connected device to her account: 827 Alice2> device complete 828 Device UDF = MBAY-U7J2-UC3W-OMBO-RKNN-ZUTA-LDJD 829 Account = alice@example.com 830 Account UDF = MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 832 4.2.2. PIN Connection 834 Alice connects a third device using the PIN code connection 835 mechanism: 837 The Alice begins the connection process by creating a one time use 838 PIN authentication code on her administration device. The PIN 839 creation request specifies the rights to be granted to the connecting 840 device: 842 Alice> account pin /threshold 843 PIN=AAIL-HF4K-QHP4-L6S2-ICJD-PQGJ-2Y 844 (Expires=2021-10-22T17:46:55Z) 846 A connection request is made on the connecting device as before 847 except that this time the PIN is specified. This time, only the 848 'threshold' right is granted. 850 Alice3> device request alice@example.com /pin ^ 851 AAIL-HF4K-QHP4-L6S2-ICJD-PQGJ-2Y 852 Device UDF = MD6Z-NHVM-TW6Y-VSML-VG7B-NB64-G55H 853 Witness value = HVJP-STQC-ACYJ-5XA7-VNXP-XKSX-HTZI 855 Since the connection request is pre-authenticated by the PIN, it is 856 not necessary for Alice to review the connection request. The 857 connection request is accepted automatically when the administration 858 device is synchronized: 860 Alice> message pending 861 MessageID: HVJP-STQC-ACYJ-5XA7-VNXP-XKSX-HTZI 862 Connection Request:: 863 MessageID: HVJP-STQC-ACYJ-5XA7-VNXP-XKSX-HTZI 864 To: From: 865 Device: MD6Z-NHVM-TW6Y-VSML-VG7B-NB64-G55H 866 Witness: HVJP-STQC-ACYJ-5XA7-VNXP-XKSX-HTZI 867 MessageID: NAD6-OXFL-AHUC-QPDU-XEZE-7ROV-6Y2U 868 Group invitation:: 869 MessageID: NAD6-OXFL-AHUC-QPDU-XEZE-7ROV-6Y2U 870 To: alice@example.com From: alice@example.com 871 MessageID: NBOJ-ONZ3-52NB-SGW3-EJQR-XGBQ-JHET 872 Confirmation Request:: 873 MessageID: NBOJ-ONZ3-52NB-SGW3-EJQR-XGBQ-JHET 874 To: alice@example.com From: console@example.com 875 Text: start 876 MessageID: NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 877 Contact Request:: 878 MessageID: NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 879 To: alice@example.com From: bob@example.com 880 PIN: AC2D-VGFI-S4BP-NKBL-XHEQ-FVNN-JPSA 881 Alice> account sync /auto 883 Alice can now synchronize her newly connected device to her account: 885 Alice3> device complete 886 Device UDF = MD6Z-NHVM-TW6Y-VSML-VG7B-NB64-G55H 887 Account = alice@example.com 888 Account UDF = MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 889 Alice3> account sync 891 >>>> Unfinished ArchitectureConnectPin/Connect.ConnectPINComplete 892 The Dynamic QRCode connection scheme uses exactly the same mechanism 893 except that instead of the PIN being presented to Alice in the form 894 of an alphanumeric string, the connection information is encoded as a 895 URI and presented to the connecting device as a QR code. 897 The URI corresponding to the connection PIN is: 899 mcu://alice@example.com/AAIL-HF4K-QHP4-L6S2-ICJD-PQGJ-2Y 901 4.2.3. Making use of the new device 903 Having connected a second device and granted it web access rights, 904 Alice can use it to decrypt files and access her bookmark and 905 password catalogs in exactly the same fashion as the first. If a 906 password is changed on one device, all her connected devices receive 907 the update. 909 For example, because Alice granted the device the Web role, she can 910 now access her credential catalog and decrypt the file she encrypted 911 on her first device from the new device: 913 Alice2> password get ftp.example.com 914 alice1@ftp.example.com = [password] 916 Alice2> dare decode ciphertext.dare plaintext2.txt 917 Alice2> type plaintext2.txt 918 This is a test 920 By default, devices connected with the web access right can access 921 all the catalogs connected to a personal Mesh. Devices MAY be 922 connected with greater or lesser access rights according to their 923 intended use. A coffee pot does not require access to the password 924 catalog or the ability to send messages to other Mesh users. A 925 software development station is likely to require the ability to sign 926 commits to a source code repository. 928 Limiting the access rights granted to a device when it is connected 929 mitigates the consequences of the device being lost, stolen or 930 infected by malware before the compromise occurs. Disconnecting the 931 device from the user's personal Mesh as described in a later section 932 provides further mitigation. 934 4.2.4. Applications 936 Connected devices can also make use of connected applications for 937 which they are granted the necessary rights. 939 Alice creates an SSH profile within her Mesh on the administrative 940 device making the private key information available to devices she 941 has connected to her Mesh with the 'web' access right. 943 Alice> ssh create /web 944 Udf: MAFP-UH3E-DVOM-KBBB-ZVQ4-QPDW-JXHR/n 946 She can extract the private key to configure her SSH clients: 948 Alice> ssh private /file=alice1_ssh_prv.pem 950 She can also extract her public key to configure her SSH server to 951 allow access to the machine: 953 Alice> ssh public /file=alice1_ssh_pub.pem 955 Ideally these steps would be performed on Alice's behalf by an 956 automated script that detects the applications Alice has installed on 957 her device and performs the necessary configuration on her behalf. 959 The SSH keys created on one device are available to every device 960 connected by the 'web' access right: 962 Alice2> account sync 963 Alice2> ssh private /file=alice2_ssh_prv.pem 965 At present the Mesh only supports an SSH configuration in which a 966 single client key is shared across multiple devices. The Mesh is in 967 principle capable of supporting more sophisticated configurations in 968 which each device has its own individual client key. Consideration 969 of these configuration modes is currently outside the scope of work 970 for the Mesh and is probably more usefully considered as part of an 971 effort to integrate Mesh functionality into the SSH system. Such an 972 effort would also describe the means by which SHH server key 973 fingerprints are recorded in the Mesh Contacts catalog. 975 Support for SMTP mail with OpenPGP and S/MIME end to end security is 976 supported in a similar fashion. 978 4.2.5. Threshold Key Devices 980 As is to be expected of a Threshold Key Infrastructure, Mesh devices 981 MAY be configured to use a threshold key share for decryption, the 982 other key share being held by the Mesh service servicing the account. 984 Connecting a device with the threshold access right grants it the 985 same range of functionality as the web access right for as long as it 986 is connected to the user's personal Mesh. Instead of being 987 provisioned with the account decryption key, the device is 988 provisioned with a key share. To decrypt documents encrypted to the 989 account key, the device requires the active participation of the 990 service holding the other half of the shared key. This allows the 991 service to prevent further use of the decryption capability by the 992 device after it has been disconnected from that personal Mesh. 994 Provisioning devices with threshold access rights has the advantage 995 of allowing greater control of the decryption capability at the cost 996 of requiring an interaction with the network service for each 997 decryption operation. There is thus a tradeoff between performance 998 and security. 1000 While the Mesh architecture permits any decryption key to be 1001 threshold shared, it is RECOMMENDED that implementations use this 1002 capability sparingly and develop mechanisms that avoid the need for a 1003 device to preform repeated threshold operations to decrypt the same 1004 data. For example, rather than decrypting every entry in the 1005 password catalog each time it is used, a device should encrypt a 1006 primary secret under the account threshold key that can be decrypted 1007 each time the device is activated and re-encrypt threshold encrypted 1008 data to that secret each time a threshold decryption is performed. 1009 This provides the same security properties with considerably less 1010 load on the service. 1012 The current version of the Mesh protocols require that the 1013 administration device used to provision threshold keys to a device 1014 have access to the original key. As described in 1015 [draft-hallambaker-mesh-schema], this requirement will be lifted in a 1016 future edition of the protocol. 1018 4.3. Mesh Messaging 1020 The Mesh Messaging system is a push messaging system analogous to 1021 SMTP, but its purpose is limited to secure exchange of control plane 1022 messages. This leads to some important differences: 1024 * Every message is signed and end-to-end encrypted 1026 * The only communication pattern supported is a four-corner model in 1027 which users exchange messages through their respective MSPs. 1029 * Every message is subject to access control at the inbound and 1030 outbound MSP. 1032 * Message content is limited to 32KB. 1034 This size restriction ensures that exchange of Mesh Messages does not 1035 impose an undue burden on the inbound and outbound MSP. While users 1036 can and do send much larger messages, 32KB should be more than 1037 sufficient to demonstrate to the recipient that the message should be 1038 accepted. It is not necessary for a sender to transfer multiple MB 1039 message before the receiver decides to refuse it. Connected devices 1040 may efficiently synchronize their message spools even over limited 1041 bandwidth connections. A short message is never blocked by a larger 1042 one. 1044 For exchange of longer messages, a pull model is employed. A short 1045 Mesh message sent a message advising the recipient's client of the 1046 location from which the full content may be obtained. This approach 1047 has many benefits over the SMTP push model. There is no longer a 1048 need for any limitation on message size. The same messaging platform 1049 can be used to send a short text message, a spreadsheet or raw video 1050 file archives spanning multiple TB. 1052 Exchange of certain content types naturally leads to security 1053 concerns. These concerns are mitigated in the Mesh by performing 1054 access control on every message. When accepting Bob as a partner, 1055 Alice can choose the types of Mesh Message and the types of content 1056 she is willing to accept from him. Thus, Alice might be willing to 1057 accept a spreadsheet containing macro code from Bob but not from 1058 Carol or Mallet. And she might not want to accept anything at all 1059 from Susan because of past abuse. 1061 While there are important technical differences between Mesh 1062 Messaging and SMTP, these are not visible to Alice or Bob except 1063 insofar as there is no restriction on message size other than the 1064 storage capacity of the machine they wish to receive the messages on, 1065 there is very little scope for messaging abuse and (unless the Mesh 1066 becomes ubiquitous) they can only use Mesh Messaging to communicate 1067 with other Mesh users. Thus, while Mesh messaging has been designed 1068 to enable replacement of SMTP in the long term, it is not currently a 1069 focus for the client implementations. Use of Mesh messaging is thus 1070 currently limited to support for applications built on the Mesh 1071 platform. One of those applications is the device connection 1072 protocol describe earlier. Another is the contact exchange protocol 1073 used to acquire contact information from other Mesh users. 1075 4.3.1. Contact exchange 1077 Besides management of private keys across devices, the biggest 1078 obstacle to effective use of existing security protocols such as SSH, 1079 OpenPGP and S/MIME is the difficulty of obtaining the authentic 1080 public keys of the counterparties. 1082 The question of issue and validation of credentials is a complex and 1083 difficult one that does not have a single answer that is valid for 1084 every use case. For certain applications credentials issued by a 1085 Trusted Third Party are appropriate. For others, the Web of Trust 1086 proposed in OpenPGP provides a better fit to the requirements and 1087 constraints. These issues are discussed in 1088 [draft-hallambaker-mesh-trust]. 1090 Rather than imposing a single trust model for credential acquisition, 1091 the Mesh allows the use of whatever model is best for validating a 1092 credential for a particular use. It is unlikely Alice would have the 1093 same security concerns for communication with her employer, her 1094 friends, her bank, etc. 1096 For many applications, Trust After First Use provides an adequate 1097 basis for credential acquisition. 1099 Alice wants to exchange Mesh messages with Bob. Although Alice knows 1100 Bob's Mesh address (bob@example.com), she does not (yet) have 1101 permission to send any message to Bob excepting a request to exchange 1102 contact information. 1104 Bob sends Alice a contact exchange request: 1106 Bob> message contact alice@example.com 1107 Envelope ID: MCN7-UWOB-VRSH-ORF2-2Q47-M6W7-NESS 1108 Message ID: NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 1109 Response ID: MA5Q-TRQI-2GMZ-JXXV-H77J-OXYP-QKMZ 1111 Alice checks his Mesh messages and approves Bob's request: 1113 Alice> account sync 1114 ERROR - The entry already exists in the store. 1115 Alice> message pending 1116 MessageID: NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 1117 Contact Request:: 1118 MessageID: NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 1119 To: alice@example.com From: bob@example.com 1120 PIN: AC2D-VGFI-S4BP-NKBL-XHEQ-FVNN-JPSA 1121 Alice> message accept NC5C-AQTH-VL6X-PTWV-BIDE-C7IF-J3OA 1122 Alice> contact list 1123 Entry: MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 1124 Person MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 1125 Anchor MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 1126 Address alice@example.com 1128 Entry: NB5L-MQ7L-EPBI-3UCI-CPWD-LI5F-FFJT 1129 Person 1130 Anchor MCFN-SXNA-2S2E-VLOC-QSE5-ZP33-EEFM 1131 Address bob@example.com 1133 Bob can now collect Alice's contact: 1135 Bob> account sync /auto 1136 Bob> contact list 1137 Entry: MCFN-SXNA-2S2E-VLOC-QSE5-ZP33-EEFM 1138 Person MCFN-SXNA-2S2E-VLOC-QSE5-ZP33-EEFM 1139 Anchor MCFN-SXNA-2S2E-VLOC-QSE5-ZP33-EEFM 1140 Address bob@example.com 1142 Entry: NAPL-37XX-T6FA-OMNS-PJ57-BMMR-J32D 1143 Person 1144 Anchor MAUA-F6QE-EJUI-GBWR-C4BH-4X5O-TLAH 1145 Address alice@example.com 1147 At this point Alice and Bob can exchange Mesh messages of any type 1148 with seamless end to end security. Every Mesh message is signed and 1149 encrypted without exception. If Alice and Bob have used the Mesh to 1150 configure their email accounts for OpenPGP or S/MIME, they can use 1151 these to exchange end-to-end secure SMTP mail. 1153 Alternatively, Bob might have opted to grant Alice only specific 1154 messaging access. Bob might choose to restrict synchronous messaging 1155 modalities such as instant messaging or voice that interrupt his 1156 workflow to specific colleagues. The fact that Alice wants to speak 1157 to Bob does not necessarily mean she is interested in what he might 1158 say in reply. Thus, messaging access need not be reciprocated. 1160 As with device connection, multiple contact exchange methods are 1161 supported including the use of a QR code printed on a business card 1162 or presented on a mobile device. These methods are also described in 1163 [draft-hallambaker-mesh-protocol]. 1165 As a respected figure within the cryptographic community, Alice might 1166 employ a curation service for credential requests advising her that 1167 Bob's credentials appear to be in order while Mallet's are 1168 suspicious. Such services might be offered by her MSP or another 1169 provider. Alice might be willing to accept contact requests from 1170 members of professional associations she is a member of or who have 1171 attended certain conferences in her field. A variety of approaches 1172 might be followed for curation of other requests including Machine 1173 Learning approaches. 1175 4.3.2. Confirmation service 1177 The Mesh confirmation service is an improvement of traditional second 1178 factor authentication techniques offering offers far greater 1179 usability and security. 1181 Instead of being asked to present a meaningless numeric code, Alice 1182 is presented a request from a named, authenticated source to confirm 1183 a specific action. Alice's response will be signed using a signature 1184 key that is unique to the particular confirmation device she uses, 1185 thus providing a non-repudiable record of her decision. 1187 Alice attempts to log into a secure console in the control room. The 1188 secure console recognizes Alice but a second factor is required. The 1189 console issues a challenge to Alice at her registered account asking 1190 if she would like to log into the secure console: 1192 Console> message confirm alice@example.com start 1193 Envelope ID: MB4F-S5G7-UD7C-HLQD-2UFO-6NC3-YWGT 1194 Message ID: NBOJ-ONZ3-52NB-SGW3-EJQR-XGBQ-JHET 1195 Response ID: MB35-ON3N-QOYV-YSRZ-EYHM-AHEY-KVNL 1197 Alice checks her pending messages and accepts the request: 1199 Alice> message accept NBOJ-ONZ3-52NB-SGW3-EJQR-XGBQ-JHET 1201 The secure console verifies the response and grants access: 1203 Console> message status MB35-ON3N-QOYV-YSRZ-EYHM-AHEY-KVNL 1204 Accept 1205 In an enterprise environment, tying the confirmation process to a 1206 specific source, a specific action and specific device allows for 1207 confirmation interactions to be used to implement business processes 1208 with attribution and thus accountability. 1210 Using traditional second factor approaches, a system administrator 1211 presents their credentials to authenticate access to the machine at 1212 which point they can perform any action permitted by their current 1213 privileges. This typically includes modification of any access logs 1214 that might be kept. Using the confirmation approach the individual 1215 actions of the system administrator may be authenticated, traced and 1216 logged. If a user account is added to the system, it is known which 1217 administrator is responsible and the device that was used. This 1218 information may then be used if it becomes necessary to unwind the 1219 consequences of a breach or an insider threat. 1221 4.4. Encryption Groups 1223 As seen earlier, the Mesh allows encrypted files to be shared with 1224 other named users. While this capability is sufficient for simple 1225 messaging type use cases, decades of experience prove that it is 1226 inadequate to meet the needs of protecting data at rest. In the 1227 simple messaging case the list of recipients is known to the sender 1228 at the time a message is sent. In the general case the party 1229 encrypting the data cannot know the list of intended readers because 1230 that will change over time. 1232 Even in the smallest organization, employees join and leave. A new 1233 employee must be granted access to all the information they need for 1234 their work. The access rights of a terminated employee must also 1235 terminate. 1237 Traditional 'Digital Rights Management' product employ key management 1238 techniques originating in the field of copyright enforcement to 1239 control access to content by controlling disclosure of symmetric 1240 decryption keys. This provides the necessary flexibility to control 1241 access to the data but leaves the decryption keys vulnerable to a 1242 server breach. Such systems do not provide 'end-to-end' security in 1243 any useful sense. 1245 Use of threshold techniques allows a threshold service to control 1246 decryption of the data without having the ability to decrypt. 1247 Sharing data through a Mesh group allows access to be controlled 1248 without loss of end-to-end encryption. 1250 Alice creates the recryption group groupw@example.com to share 1251 confidential information with her closest friends: 1253 Alice> group create groupw@example.com /web 1254 Account=groupw@example.com 1255 UDF=MDXN-776V-SVUC-EBU7-TE7G-T4NT-AWAO 1257 Alice encrypts a test file but she can't decrypt it because she 1258 hasn't added herself to the group yet. 1260 Alice> type plaintext.txt 1261 This is a test 1262 Alice> dare encode grouptext.txt groupsecret.dare /encrypt ^ 1263 groupw@example.com 1264 Alice> dare decode groupsecret.dare grouptext_alice.dare 1265 ERROR - No decryption key is available 1267 Alice adds herself to the group, now she can decrypt: 1269 Alice> group add groupw@example.com alice@example.com 1270 { 1271 "ContactAddress": "alice@example.com", 1272 "MemberCapabilityId": "MBBJ-4OUP-KC6Z-EXRK-MD2S-WUB6-OLCD", 1273 "ServiceCapabilityId": "MCWS-HVYK-YVB7-VEOE-ZQQS-TJ45-SDBR"} 1274 Alice> account sync /auto 1275 Alice> dare decode groupsecret.dare grouptext_alice.dare 1276 Alice> type grouptext_alice.dare 1277 The group secret handshake 1279 At this point, Bob can't encrypt or decrypt messages because he 1280 doesn't know the public key and he isn't in the group. Alice could 1281 allow Bob to encrypt but not decrypt by sending him the group contact 1282 information. Instead she adds Bob to the group: 1284 Alice> group add groupw@example.com bob@example.com 1285 { 1286 "ContactAddress": "bob@example.com", 1287 "MemberCapabilityId": "MBBJ-4OUP-KC6Z-EXRK-MD2S-WUB6-OLCD", 1288 "ServiceCapabilityId": "MDTV-FE77-BIZV-DPKP-HCJC-PU4N-IRFF"} 1290 Adding Bob to the group gives him immediate access to any file 1291 encrypted under the group key without making any change to the 1292 encrypted files: 1294 Bob> account sync /auto 1295 Bob> dare decode groupsecret.dare grouptext_bob.dare 1296 Bob> type grouptext_bob.dare 1297 The group secret handshake 1299 Removing Bob from the group immediately withdraws his access. 1301 Alice> group delete groupw@example.com bob@example.com 1302 { 1303 "ContactAddress": "bob@example.com", 1304 "MemberCapabilityId": "MBBJ-4OUP-KC6Z-EXRK-MD2S-WUB6-OLCD", 1305 "ServiceCapabilityId": "MDTV-FE77-BIZV-DPKP-HCJC-PU4N-IRFF"} 1307 Bob cannot decrypt files encrypted under the group key any more. But 1308 he still has access to the file grouptext_bob.dare he decrypted 1309 earlier. 1311 Bob> dare decode groupsecret.dare grouptext_bob2.dare 1312 ERROR - A cryptographic operation was refused. 1314 The threshold key service acts as a policy enforcement point and can 1315 impose additional accounting and authorization controls on the use of 1316 the decryption service. 1318 For example, the threshold key service might be configured to alert a 1319 supervisor and/or deny decryption requests if a group member made an 1320 unusual volume of requests in a short period. 1322 4.5. Deleting Devices 1324 If a connected device is lost, stolen or simply broken, Alice can 1325 limit further use of the device by disconnecting it from her Mesh: 1327 Alice disconnects the new device: 1329 Alice> device delete MBAY-U7J2-UC3W-OMBO-RKNN-ZUTA-LDJD 1331 Disconnecting a device will always prevent the device receiving 1332 further services from the account service and thus the ability to 1333 receive encrypted catalog updates. But a device connected with 1334 direct key access rights (e.g. web) is still capable of decrypting 1335 documents encrypted under the account key unless the device 1336 application discovers that it has been disconnected and deletes the 1337 corresponding keys: 1339 The device can no longer access the password catalog, but it can 1340 still decrypt files: 1342 Alice2> account sync 1343 ERROR - The server returned an invalid response. 1344 Alice2> dare decode ciphertext.dare plaintext3.txt 1345 Alice2> type plaintext3.txt 1346 This is a test 1347 A device connected with the threshold access right loses the ability 1348 to decrypt immediately: 1350 The third device was connected with threshold rights, it is 1351 disconnected in the same way as before. 1353 Alice> device delete MD6Z-NHVM-TW6Y-VSML-VG7B-NB64-G55H 1355 The device can no longer access the password catalog or decrypt 1356 files: 1358 Alice3> account sync 1359 ERROR - The server returned an invalid response. 1360 Alice3> dare decode ciphertext.dare plaintext3.txt 1361 ERROR - A cryptographic operation was refused. 1363 4.6. Escrow and Recovery 1365 While disclosure of sensitive data might cause serious harm to its 1366 owner it is very rarely the case that the consequences of disclosure 1367 are greater than the consequences of loss. Thus, whenever static 1368 data is to be encrypted, the question of key recovery must be 1369 considered. 1371 Alice decides to create a recovery key set. To do this, she 1372 specifies the number of key shares to be created and the number 1373 required for recovery: 1375 Alice> account escrow 1376 Share: SAQO-S3VD-2INK-6OPH-7XX6-TX5K-O7AH-Q5LI-7J5O-MGTN-7X4Z-4TFY-RL 1377 L3-UGDM-C6OQ 1378 Share: SAQQ-VXCF-H7TI-VCVK-6PQ3-2XA7-J6BJ-JOJS-WZE5-SI4F-S3UU-NUKD-NW 1379 OS-AEFQ-SJ4A 1380 Share: SARC-YSPG-VWZG-LW3N-5HJZ-BWEU-E5CL-B7H4-OIMM-YLE5-F7MO-6VOO-KB 1381 RI-MCHV-BWAA 1383 Recovery of the key data requires the key recovery record and a 1384 quorum of the key shares: 1386 >>>> Unfinished ArchitectureRecovery 1388 Missing example 1 1390 4.7. Future Directions 1392 The Mesh is a Threshold Key Infrastructure and as with any 1393 infrastructure, it is designed as a platform to support as wide a 1394 range of future developments as possible. Selection of the initial 1395 feature set was determined by the need to achieve zero-effort 1396 security. 1398 Further development of the Mesh will require careful consideration of 1399 costs and benefits. The range of security features that could be 1400 added is infinite, the range of features that should be added is 1401 small. Real world deployment and use is required before extensive 1402 addition of new features. 1404 4.7.1. Device Disconnection 1406 While 'single sign on' gets much attention in the Enterprise 1407 computing space, it is actually 'single sign off' that provides the 1408 real security value. Future enhancements of the Mesh will consider: 1410 ?A notification mechanism to allow a disconnected device to advise 1411 the user that it has completely disconnected from the user's Mesh and 1412 deleted relevant data. 1414 ?Use of trustworthy hardware to prevent use of confidential data 1415 accessed through a personal Mesh after the device is disconnected. 1417 ?Use of threshold timed key release to limit the period during which 1418 a device has access to confidential data. 1420 4.7.2. Service Transition 1422 Allowing users to transfer their accounts from one service provider 1423 to another without switching costs is an important goal of the Mesh 1424 project. Enabling such transfers is the principal purpose of the 1425 Callsign registry [draft-hallambaker-mesh-callsign]. 1427 Support for account transition is currently limited and untested. In 1428 theory a user MAY transfer their account from one service provider to 1429 another by opening an account at the new service provider and 1430 uploading the data provided that they have access to the profile 1431 primary secret and all threshold key shares granted to the devices 1432 are regenerated. 1434 A different application of threshold cryptography and in particular 1435 the use of threshold techniques to generate key shares would allow a 1436 user to transfer their account without the need to reconstitute the 1437 primary secret. 1439 4.7.3. Threshold User Account 1441 At present the administration device has direct access to the 1442 administrator key and it is not possible to determine which device 1443 performed a particular administration action. Similarly, the 1444 administration device requires access to the full decryption keys to 1445 create threshold key shares for devices. 1447 As with the service transition issue described earlier, meeting this 1448 particular requirement using threshold cryptography is 1449 straightforward in itself. The challenge lies in meeting the 1450 requirements simultaneously. Or to be more precise, the challenge 1451 lies in understanding what the precise requirements are. 1453 A sketch has been developed of an approach addressing both sets of 1454 requirements as currently understood. Instead of using an additive 1455 key splitting approach for creating key shares, the additive approach 1456 is combined with a Shamir/Lagrange approach such that: 1458 * A single administration device can connect devices using key 1459 shares mediated by the current service. 1461 * Two administration devices can create the necessary signatures and 1462 key shares to transfer the account to a different service 1463 provider. 1465 * Two administration devices can add a third administration device 1466 with the same capabilities as the original two. 1468 Achieving the last requirement makes use of the fact that Lagrange 1469 interpolation can be used to generate additional shares without 1470 reconstructing the original secret. The x coordinate of each share 1471 holder is determined from the fingerprint of the device profile 1472 signature key. 1474 4.7.4. Threshold Group Administration 1476 The current group encryption architecture requires that the group 1477 administrator have access to the decryption key. The administrator 1478 is thus able to decrypt any documents they chose and bypass the 1479 accounting restrictions of the service. 1481 Further application of threshold techniques would allow the 1482 administrator role to be split between two or more parties, one of 1483 which might be a service enforcing additional controls. 1485 4.7.5. Synchronous Messaging 1487 Addition of a presence service capability to the MSP would allow Mesh 1488 Messaging to be used to support the full range of synchronous 1489 messaging services from text chat (e.g. xmpp) to video and VOIP. The 1490 chief security benefit to the end user for such a scheme would be 1491 that every communication request is mediated by access control. 1492 While it is impossible to absolutely guarantee that every possible 1493 form of abuse is prevented, stopping the organized crime ring that 1494 just called me purporting to be my credit card company is much more 1495 straightforward. 1497 The main technical issue to be addressed to enable such a service is 1498 specifying a means of layering Mesh Messages direct over UDP 1499 transport. This is currently at the concept phase. While the 1500 precise means of layering audio and video formats onto a network 1501 connection is a complex problem, it is one that has already been 1502 solved by existing standards. 1504 4.7.6. Social Media 1506 One of the chief distinctions between messaging and 'social media' 1507 and is that the former is typically used to describe a synchronous 1508 interaction between a closed group of users while most social media 1509 consists of asynchronous interactions which are frequently (but not 1510 always) public. 1512 The Data At Rest Envelope technology used in the Mesh was originally 1513 designed to support asynchronous social media interactions with full 1514 end-to-end confidentiality. The service hosting a forum or 1515 discussion board need not have access to the content of the messages 1516 to support the complete range of user interactions. 1518 5. Mesh Cryptography 1520 All the cryptographic algorithms used in the Mesh are either industry 1521 standards or present a work factor that is provably equivalent to an 1522 industry standard approach. Since threshold cryptography is not 1523 currently part of the 'canon' from which designers of cryptographic 1524 security protocols work, much of the cryptography used in the Mesh 1525 has been designed for the Mesh. Despite this fact, it is properly 1526 regarded as part of the Internet platform on which the Mesh is built 1527 rather than a part of the Mesh itself. 1529 Existing Internet security protocols are based on approaches 1530 developed in the 1990s when performance tradeoffs were a prime 1531 consideration in the design of cryptographic protocols. Security was 1532 focused on the transport layer as it provided the best security 1533 possible given the available resources. 1535 With rare exceptions, most computing devices manufactured in the past 1536 ten years offer either considerably more computing power than was 1537 typical of 1990s era Internet connected machines or considerably 1538 less. The Mesh architecture is designed to provide security 1539 infrastructure both classes of machine but with the important 1540 constraint that the less capable 'constrained' devices are considered 1541 to be 'network capable' rather than 'Internet capable' and that the 1542 majority of Mesh related processing will be offloaded to another 1543 device. 1545 For example, Alice uses her Desktop and Laptop to exchange end-to-end 1546 secure Mesh Messages and documents but her Internet-of-Things food 1547 blender and light bulb are limited in the range of functions they 1548 support and the telemetry information they provide. The IoT devices 1549 connect to a Mesh Hub which acts as an always-on point of presence 1550 for the device state and allows complex cryptographic operations to 1551 be offloaded if necessary. 1553 (Artwork only available as svg: No external link available, see 1554 draft-hallambaker-mesh-architecture-19.html for artwork.) 1556 Figure 2: Constrained Devices connected through a Mesh Hub. 1558 5.1. Best Practice by Default 1560 Except where support for external applications demand otherwise, the 1561 Mesh requires that the following 'best practices' be followed: 1563 Industry Standard Algorithms All cryptographic protocols make use of 1564 the most recently adopted industry standard algorithms. 1566 Strongest Work Factor Only the strongest modes of each cipher 1567 algorithm are used. All symmetric encryption is performed with 1568 256-bit session keys and all digest algorithms are used in 512-bit 1569 output length mode. 1571 Key Hygiene Separate public key pairs are used for all cryptographic 1572 functions: Encryption, Signature and Authentication. This enables 1573 separate control regimes for the separate functions and 1574 partitioning of cryptographic functions within the application 1575 itself. 1577 Bound Device Keys Each device has a separate set of Encryption, 1578 Signature and Authentication key pairs. These MAY be bound to the 1579 device to which they are assigned using hardware or other 1580 techniques to prevent or discourage export. 1582 No Optional Extras Traditional approaches to security have treated 1583 many functions as being 'advanced' and thus suited for use by only 1584 the most sophisticated users. The Mesh rejects this approach 1585 noting that all users operate in precisely the same environment 1586 facing precisely the same threats. 1588 Industry best practices change over time. In the 1990s it was 1589 generally believed that supporting the widest possible range of 1590 cryptographic algorithms allowed the greatest highest level of 1591 security. This view has been decisively rejected in the light of the 1592 objection that a successful downgrade attack results in the security 1593 afforded by the weakest algorithm supported. 1595 5.2. Multi-Level Security 1597 All Mesh protocol transactions are protected at the Transport, 1598 Message and Data level. This provides security in depth that cannot 1599 be achieved by applying security at the separate levels 1600 independently. Data level encryption provides end-to-end 1601 confidentiality and non-repudiation, Message level authentication 1602 provides the basis for access control and Transport level encryption 1603 provides a degree of protection against traffic analysis. 1605 5.3. Threshold Decryption 1607 Traditional public key encryption algorithms have two keys, one for 1608 encryption and another for decryption. The Mesh makes use of 1609 threshold cryptography techniques to allow the decryption key to be 1610 split into two or more parts. 1612 For example, if we have a private key _z_, we can use this to perform 1613 a key agreement with a public key _S_ to obtain the key agreement 1614 value A. But if _z_ = (_x+y_) mod _g_ (where g is the order of the 1615 group). we can obtain the exact same result by applying the private 1616 keys _x_ and _y_ to _S_ separately and combining the results: 1618 (Artwork only available as svg: No external link available, see 1619 draft-hallambaker-mesh-architecture-19.html for artwork.) 1621 Figure 3: Two key decryption. 1623 The approach to threshold decryption used in the Mesh was originally 1624 inspired by the work of Matt Blaze et. al. on proxy re-encryption. 1625 But the approach used may also be considered a form of Torben 1626 Pedersen's Distributed Key generation which is in turn one form of 1627 threshold cryptography. 1629 This technique is used in the Mesh to allow use of decryption key 1630 held by a user to be controlled by a cloud service without giving the 1631 cloud service the ability to decrypt by itself. 1633 These techniques are described in detail in 1634 [draft-hallambaker-threshold]. 1636 5.4. Threshold Key Generation 1638 The mathematics that support threshold decryption are also the basis 1639 for the multi-party key generation mechanism that is applied at 1640 multiple levels in the Mesh. The basis for the multi-party key 1641 generation used in the Mesh is that for any Diffie-Hellman type 1642 cryptographic scheme, given two keypairs { _x_, _X_ }, { _y_, _Y_ }, 1643 we calculate the public key corresponding to the private key _x_+ _y_ 1644 using just the public key values _X_and _Y_. 1646 (Artwork only available as svg: No external link available, see 1647 draft-hallambaker-mesh-architecture-19.html for artwork.) 1649 Figure 4: Two party key pair generation. 1651 Threshold key generation ensures that keys used to bind devices to a 1652 personal Mesh or within a Mesh account are 'safe' if any of the 1653 contributions to the generation process are safe. 1655 These techniques are also described in detail in 1656 [draft-hallambaker-threshold]. 1658 5.5. Threshold Signature 1660 The techniques that support threshold decryption and key generation 1661 are also applicable to signature albeit with some very important 1662 constraints. Incorrect implementation of the techniques used to 1663 create ECDSA signatures can result in disclosure of the private key. 1664 It is therefore essential that a threshold signature algorithm is 1665 rigorously reviewed. 1667 This technique is used in the mesh to partition the use of 1668 administration keys so that the consequences of losing an 1669 administrative device can be mitigated. 1671 These techniques are currently being developed by the CFRG. This 1672 work is currently described in [draft-irtf-cfrg-frost]. 1674 5.6. Data At Rest Encryption 1676 The Data At Rest Encryption (DARE) format is used for all 1677 confidentiality and integrity enhancements. The DARE format is based 1678 on the JOSE Signature and Encryption formats and the use of an 1679 extended version of the JSON encoding allowing direct encoding of 1680 binary objects. 1682 5.6.1. DARE Envelope 1684 The DARE Envelope format offers similar capabilities to existing 1685 formats such as OpenPGP and CMS without the need for onerous encoding 1686 schemes. DARE Assertions are presented as DARE Envelopes. 1688 A feature of the DARE Envelope format not supported in existing 1689 schemes is the ability to encrypt and authenticate sets of data 1690 attributes separately from the payload. This allows features such as 1691 the ability to encrypt a subject line or content type for a message 1692 separately from the payload. 1694 5.6.2. Dare Sequence 1696 A DARE Sequence is an append-only sequence of DARE Envelopes. A key 1697 feature of the DARE Sequence format is that entries MAY be encrypted 1698 and/or authenticated incrementally. Individual entries MAY be 1699 extracted from a DARE Sequence to create a stand-alone DARE Envelope. 1701 Sequences may be authenticated by means of a Merkle tree of digest 1702 values on the individual frames. This allows similar demonstrations 1703 of integrity to those afforded by Blockchain to be provided but with 1704 much greater efficiency. 1706 Unlike traditional encryption formats which require a new public key 1707 exchange for each encrypted payload, the DARE Sequence format allows 1708 multiple entries to be encrypted under a single key exchange 1709 operation. This is particularly useful in applications such as 1710 encrypting server transaction logs. The server need only perform a 1711 single key exchange operation each time it starts to establish a new 1712 shared secret for that session. The shared secret is then used to 1713 create fresh symmetric keying material for each entry in the log 1714 using a unique nonce per entry. 1716 (Artwork only available as svg: No external link available, see 1717 draft-hallambaker-mesh-architecture-19.html for artwork.) 1718 Figure 5: DARE Sequence containing a transaction log. 1720 Integrity is provided by a Merkle tree calculated over the sequence 1721 of log entries. The tree apex is signed at regular intervals to 1722 provide non-repudiation. 1724 Four types of DARE Sequence are used in the mesh 1726 Catalogs A DARE Sequence whose entries track the status of a set of 1727 related objects which may be added, updated, or deleted. 1729 Spools A DARE Sequence whose entries track the status of a series of 1730 Mesh Messages. 1732 Logs A DARE Sequence recording a sequence of events. 1734 Archives A DARE Sequence containing a collection of files, each 1735 encoded in a DARE envelope. DARE archives perform a similar 1736 function to ZIP archives except that the primary objective is to 1737 support confidentiality and integrity rather than data 1738 compression. 1740 5.7. Uniform Data Fingerprints. 1742 The Uniform Data Fingerprint (UDF) format provides a compact means of 1743 presenting cryptographic nonces, keys and digest values using Base32 1744 encoding that resists semantic substitution attacks. UDF provides a 1745 convenient format for data entry. Since the encoding used is case- 1746 insensitive, UDFs may if necessary be read out over a voice link 1747 without excessive inconvenience. 1749 The following are examples of UDF values: 1751 NAXT-YHV5-YWQH-UWN3-JMVZ-KXJL-M4AA 1752 NNAT-CQK3-WCXP-2WAJ-TOYO-2JAP-PU 1753 SAQG-DD3P-GJZO-J6C5-PRZO-N76V-ICYK-E 1754 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 1755 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 1756 AAPM-OQ5Q-AUDS-4VDG-BHDH-VKWU-SORK 1758 UDF content digests are used to support a direct trust model similar 1759 to that of OpenPGP. Every Mesh Profile is authenticated by the UDF 1760 fingerprint of its signature key. Mesh Friendly Names and UDF 1761 Fingerprints thus serve analogous functions to DNS names and IP 1762 Addresses. Like DNS names, Friendly Names provide the basis for 1763 application-layer interactions while the UDF Fingerprints are used as 1764 to provide the foundation for security. 1766 5.7.1. Friendly Names 1768 Internet addressing schemes are designed to provide a globally unique 1769 (or at minimum unambiguous) name for a host, service or account. In 1770 the early days of the Internet, this resulted in addresses such as 1771 10.2.3.4 and alice@example.com which from a usability point of view 1772 might be considered serviceable if not ideal. Today the Internet is 1773 a global infrastructure servicing billions of users and tens of 1774 billions of devices and accounts are more likely to be 1775 alice.lastname.1934@example.com than something memorable. 1777 Friendly names provide a user or community specific means of 1778 identifying resources that may take advantage of geographic location 1779 or other cues to resolve possible ambiguity. If Alice says to her 1780 voice activated device "close the garage door" it is implicit that it 1781 is her garage door that she wishes to close. And should Alice be 1782 fortunate enough to own two houses with a garage, it is implicit that 1783 it is the garage door of the house she is presently using that she 1784 wishes to close. 1786 The Mesh Device Catalog provides a directory mapping friendly names 1787 to devices that is available to all Alice's connected devices so that 1788 she may give and instruction to any of her devices using the same 1789 friendly name and expect consistent results. 1791 5.7.2. Encrypted Authenticated Resource Locators 1793 Various schemes have been used to employ QR Codes as a means of 1794 device and/or user authentication. In many of these schemes a QR 1795 code contains a challenge nonce that is used to authenticate the 1796 connection request. 1798 The Mesh supports a QR code connection mode employing the Encrypted 1799 Authenticated Resource Locator (EARL) format. An EARL is an 1800 identifier which allows an encrypted data object to be retrieved and 1801 decrypted. In this case, the encrypted data object contains the 1802 information needed to complete the interaction. 1804 An EARL contains the domain name of the service providing the 1805 resolution service and an encryption master key: 1807 mcu://maker@example.com/EBVO-EJPF-3N7D-RI4K-5EQG-XC2X-JA 1809 The EARL may be expressed as a QR code: 1811 (Artwork only available as svg: No external link available, see 1812 draft-hallambaker-mesh-architecture-19.html for artwork.) 1813 Figure 6: QR Code representation of the EARL 1815 An EARL is resolved by presenting the content digest fingerprint of 1816 the encryption key to a Web service hosted at the specified domain. 1817 The service returns a DARE Envelope whose payload is encrypted and 1818 authenticated under the specified master key. Since the content is 1819 stored on the service under the fingerprint of the key and not the 1820 key itself, the service cannot decrypt the plaintext. Only a party 1821 that has access to the encryption key in the QR code can decrypt the 1822 message. 1824 5.7.3. Secure Internet Names 1826 Secure Internet Names bind an Internet address such as a URL or an 1827 email address to a Security Policy by means of a UDF content digest 1828 of a document describing the security policy. This binding enables a 1829 SIN-aware Internet client to ensure that the security policy is 1830 applied when connecting to the address. For example, ensuring that 1831 an email sent to an address must be end-to-end encrypted under a 1832 particular public key or that access to a Web Service requires a 1833 particular set of security enhancements. 1835 alice@example.com Alice's regular email address (not a SIN). 1837 alice@mm--maua-f6qe-ejui-gbwr-c4bh-4x5o-tlah.example.com A strong 1838 email address for Alice that can be used by a regular email 1839 client. 1841 alice@example.com.mm--maua-f6qe-ejui-gbwr-c4bh-4x5o-tlah A strong 1842 email address for Alice that can only used by an email client that 1843 can process SINs. 1845 Using an email address that has the Security Policy element as a 1846 prefix allows a DNS wildcard element to be defined that allows the 1847 address to be used with any email client. Presenting the Security 1848 Policy element as a suffix means it can only be resolved by a SIN- 1849 aware client. 1851 5.8. Personal Key Escrow 1853 One of the core objectives of the Mesh is to make data level 1854 encryption ubiquitous. While data level encryption provides robust 1855 protection of data confidentiality, loss of the ability to decrypt 1856 means data loss. 1858 For many Internet users, data availability is a considerably greater 1859 concern than confidentiality. Ten years later, there is no way to 1860 replace pictures of the children at five years old. Recognizing the 1861 need to guarantee data recovery, the Mesh provides a robust personal 1862 key escrow and recovery mechanism. Lawful access is not supported as 1863 a requirement. 1865 Besides supporting key recovery in the case of loss, the Mesh 1866 protocols potentially support key recovery in the case of the key 1867 holder's death. The chief difficulty faced in implementing such a 1868 scheme being developing an acceptable user interface which allows the 1869 user to specify which of their data should survive them and which 1870 should not. As the apothegm goes: Mallet wants his beneficiaries to 1871 know where he buried Aunt Agatha's jewels but not where he buried 1872 Aunt Agatha. 1874 The Mesh supports use of Shamir/Lagrange secret sharing and recovery 1875 to split a secret key into a set of shares, a predetermined number of 1876 which may be used to recover the original secret. For convenience 1877 secret shares are represented using UDF allowing presentation in 1878 Base32 (i.e. text format) for easy transcription or QR code 1879 presentation if preferred. 1881 To facilitate escrow and recovery, all the public key pairs and key 1882 shares associated with a Mesh profile are generated from a seed value 1883 using a deterministic algorithm. Thus, escrow of the seed value is 1884 sufficient to permit recovery of the private key data. 1886 For example, Alice escrows her Mesh Profile creating three recovery 1887 shares, two of which are required to recover the master secret: 1889 (Artwork only available as svg: No external link available, see 1890 draft-hallambaker-mesh-architecture-19.html for artwork.) 1892 Figure 7: Use of Shamir/Lagrange Secret Sharing to create a 1893 recovery record. 1895 To recover the master secret, Alice presents the necessary number of 1896 key shares. These are used to recover the master secret which is 1897 used to generate the decryption key: 1899 (Artwork only available as svg: No external link available, see 1900 draft-hallambaker-mesh-architecture-19.html for artwork.) 1902 Figure 8: Use of Shamir/Lagrange Secret Recovery to recover a 1903 master key set. 1905 A user may choose to store their encrypted recovery record themselves 1906 or make use of the EARL mechanism to store the information at one or 1907 more cloud services using the fingerprint of the master secret as the 1908 locator. 1910 6. Mesh Architecture 1912 The Mesh infrastructure is supported by a compact set of structures 1913 and protocols. These are discussed in detail in the Schema Reference 1914 [draft-hallambaker-mesh-schema] and Protocol Reference 1915 [draft-hallambaker-mesh-protocol] documents. 1917 The JSON object model and JSON or JSON-B serialization 1918 [draft-hallambaker-jsonbcd] are used for all Mesh data structures. 1919 These include: 1921 Assertions A DARE envelope containing a signed data object. 1922 Assertions include Profiles and Connections. 1924 Profile A self-signed assertion describing a Mesh principal. 1925 Principals include Accounts, Devices and Services. 1927 Every profile specifies a profile signature key under which it is 1928 signed. The UDF fingerprint of the profile signature key is used 1929 as a unique identifier for the profile. Thus, all attributes 1930 declared in the profile such as authentication keys and encryption 1931 keys are bound to the unique identifier for the profile. 1933 Connection An assertion signed by one principal delegating rights to 1934 another. Connection assertions are used to bind devices to 1935 accounts and hosts to a service. 1937 Activation A DARE envelope encrypted under the encryption key of a 1938 principal that grant rights or capabilities to that principal. 1939 This is typically but not always achieved through use of threshold 1940 key techniques. 1942 Message A DARE envelope signed by the sender that is encrypted under 1943 the encryption key of the intended recipient(s) whose content is a 1944 Mesh messaging object. 1946 Entry An object stored in a catalog that carries an identifier that 1947 is unique for that catalog. 1949 6.1. Actors 1951 Three Mesh actors are defined: Accounts, Devices and Services. Each 1952 of these is described by a specific type of profile. 1954 6.1.1. Account 1956 Two types of Mesh account are currently specified: personal accounts 1957 and group accounts. For concise exposition, this document is limited 1958 to the description of personal accounts. Group accounts are 1959 specified in the Schema Reference [draft-hallambaker-mesh-schema]. 1961 A Mesh account is an abstraction which may be loosely regarded as the 1962 thing to which a collection of devices (in the case of a user 1963 account) or a collection of members (in the case of a group account) 1964 belong. 1966 Each personal account profile specifies: 1968 Profile Signature Key Used to authenticate the profile. Updates to 1969 the profile require use of the Profile Signature Key. The Profile 1970 Signature Key cannot be changed but a profile may be replaced by a 1971 new profile. 1973 Uniform Data Fingerprint The UDF fingerprint of the Profile 1974 Signature Key. This is used as a unique identifier for the 1975 account. 1977 Account Name The account name through which the profile is serviced. 1979 Administration Keys UDF fingerprint of keys that are authorized to 1980 sign device connection assertions and update the Device Catalog. 1982 Signature Key Public parameters of the account signature key. This 1983 is the key that counterparties will use to verify messages sent by 1984 the account holder. 1986 Encryption Key Public parameters of the account encryption key. 1987 This is the key that counterparties will use to encrypt messages 1988 sent to the account holder. 1990 Authentication Key Public parameters of the account authentication 1991 key. This is the key that counterparties will use to establish 1992 authenticated exchanges with the account holder. 1994 The public keys for encryption, authentication and signature 1995 specified in the account profile are the only keys that will (in 1996 normal circumstances) be visible to other Mesh accounts. 1998 6.1.2. Device 2000 A Mesh Device is any device that is connected to a Mesh Account 2001 through a Device profile. A given physical device may have multiple 2002 device profiles associated with it but for the purposes of the Mesh, 2003 these are considered to be separate devices. A given device profile 2004 may be connected to more than one account 2006 The device profile specifies: 2008 Profile Signature Key Used to authenticate the profile. Updates to 2009 the profile require use of the Profile Signature Key. The Profile 2010 Signature Key cannot be changed but a profile may be replaced by a 2011 new profile. 2013 Uniform Data Fingerprint The UDF fingerprint of the Profile 2014 Signature Key. This is used as a unique identifier for the device. 2016 Signature Key Public parameters of the device signature key share. 2017 This key share is used as a contribution to the signature key the 2018 device will use in the context of the account and to authenticate 2019 device connection requests. 2021 Encryption Key Public parameters of the account encryption key 2022 share. This key share is used as a contribution to the encryption 2023 key the device will use in the context of the account and to 2024 decrypt activation records sent in response to device connection 2025 requests. 2027 Authentication Key Public parameters of the account authentication 2028 key share. This key share is used as a contribution to the 2029 authentication key the device will use in the context of the 2030 account. 2032 Description Optional information describing the device provided by 2033 the manufacturer. E.g. model, serial number, date of manufacture 2034 etc. 2036 A Mesh Device is connected to an account through the creation of an 2037 activation record and a connection record. 2039 The activation record contains key shares that are overlaid on the 2040 corresponding shares specified in the device profile to create the 2041 set of encryption, authentication and signature keys the device will 2042 use in the context of the account. Since the private keys 2043 corresponding to the device profile keys are only used to enable the 2044 connection of the device to an account, these keys are only trusted 2045 to a minimal degree. 2047 (Artwork only available as svg: No external link available, see 2048 draft-hallambaker-mesh-architecture-19.html for artwork.) 2050 Figure 9: Activation of an account key set. 2052 In the ideal case, the device profile keys are fixed to the device 2053 such that they may be used to perform private key operations without 2054 the ability to extract the private key data from the device. Since 2055 the device profile is only trusted for the limited purpose of 2056 connecting the device to an account, the device profile may be 2057 created during manufacture without undue concern for either 2058 disclosure of the private key on the part of the account holder or a 2059 reputation attack alleging disclosure of the private key on the part 2060 of the manufacturer. 2062 The device connection record is functionally a certificate that the 2063 device may use to interact with the Mesh Service or to other devices 2064 connected to the same account. Note however that use of threshold 2065 cryptography means that Mesh devices would not normally present their 2066 device connection record to any other party since all communication 2067 with external parties takes place through the keys published in the 2068 account profile. 2070 6.1.3. Service 2072 A Mesh Service is an abstract network service that is provided by one 2073 or more hosts. The properties of the service are described by the 2074 service profile. 2076 The service profile specifies: 2078 Profile Signature Key Used to authenticate the profile. Updates to 2079 the profile require use of the Profile Signature Key. The Profile 2080 Signature Key cannot be changed but a profile may be replaced by a 2081 new profile. 2083 Uniform Data Fingerprint The UDF fingerprint of the Profile 2084 Signature Key. This is used as a unique identifier for the device. 2086 Signature Key Public parameters of the service signature key. This 2087 is the key that counterparties will use to verify messages sent by 2088 the service. 2090 Encryption Key Public parameters of the service encryption key. 2091 This is the key that counterparties will use to encrypt messages 2092 sent to the service. 2094 Authentication Key Public parameters of the account authentication 2095 key. This is the key that counterparties will use to establish 2096 authenticated exchanges with the service. 2098 Hosts are Mesh Devices that have been granted a Host Activation and 2099 Host Connection by a service administrator. These are used in the 2100 same fashion as the device activation and connection records. 2102 6.2. Stores 2104 Mesh Stores are append-only sequences that are used to represent 2105 collections of objects, messages and data. All Mesh stores are 2106 implemented as DARE Sequences authenticated by means of a Merkle 2107 tree. The payload of each envelope in the sequence is usually 2108 encrypted. 2110 Two types of Mesh store are currently defined: 2112 Catalog A set of Mesh objects, each of which has an identifier that 2113 is unique in the scope of the catalog. Objects may be added, 2114 updated, and deleted. 2116 Spool A sequence of Mesh Messages. 2118 All the state represented within a Mesh account is contained in Mesh 2119 stores bound to the account. Thus, to synchronize a device to the 2120 state of the account, it is sufficient to synchronize the collection 2121 of stores the device is permitted to read. Since every store is an 2122 append-only sequence, it is sufficient for the Mesh service to return 2123 the envelopes added to each of the stores since the device was last 2124 synchronized. 2126 Rapid synchronization of catalogs and spools is ensured by limiting 2127 the size of entries to each. Implementations may further improve 2128 performance by redacting stores to remove obsolete entries that have 2129 been updated or deleted. Alternatively, a device may maintain a 2130 complete record of the state of the store to allow erroneous changes 2131 to the store to be unwound. 2133 6.2.1. Catalogs 2135 Mesh Catalogs track a collection of entries. Every Mesh account 2136 contains a Threshold Catalog that is used by Mesh services as the 2137 source of access control policy. The Threshold Catalog is unique in 2138 that it is the only catalog whose contents can be read by the Mesh 2139 Service. Every other Mesh Catalog connected to a Mesh account is 2140 end-to-end encrypted so that it can only be read by devices connected 2141 to the account. 2143 The Mesh specifies various catalogs that are used to track 2144 information relevant to a Mesh Account: 2146 Device The devices connected to the corresponding Mesh profile. 2148 Contact Logical and physical contact information for people and 2149 organizations. 2151 Bookmark Web bookmarks and citations. 2153 Credential Username and password information for network resources. 2155 Calendar Appointments and tasks. 2157 Network Network access configuration information allowing access to 2158 wireless networks and VPNs. 2160 Application Configuration information for applications including 2161 mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH. 2163 Access A catalog that is readable by the Mesh Service that is used 2164 to determine access to account resources including device access 2165 rights, threshold keys and message delivery. 2167 Each catalog connected to an account has a unique identifier of the 2168 form mmm_<. Applications may specify additional catalogs 2169 without risk of collision with future Mesh catalogs by using an 2170 appropriate IANA assigned protocol label. 2172 6.2.2. Spools 2174 Spools are used to track inbound and outbound messages. Three spools 2175 are currently defined: 2177 Inbound Messages that have been received by the service and accepted 2178 for delivery to the account. 2180 Outbound Messages that have been sent from the account through the 2181 service. 2183 Local A spool used to exchange messages with devices connecting to 2184 the device. 2186 6.3. Mesh Service Protocol 2188 Mesh services communicate with Mesh devices and other Mesh Services 2189 through the Mesh Service Protocol. Despite the wide range of Mesh 2190 functionality, the Mesh protocol is remarkably compact. The bulk of 2191 the semantics associated with the Mesh are expressed in the schemas 2192 describing Mesh Messages and Catalogs. The objective of reducing the 2193 degree of trust in the Mesh service to the absolute minimum by 2194 necessity requires that the Mesh Service be extremely simple. 2196 Mesh Service Protocol transactions are divided into the following 2197 groups: 2199 Service Description The Hello transaction returns a description of 2200 the service including information used to authenticate future 2201 interactions with the service. 2203 Account Management The Create and Delete transactions are used to 2204 bind an account to a service. 2206 Device Connection The Connect and Complete transactions are used to 2207 connect devices to an account 2209 Synchronization The Status, Download and Transact transactions are 2210 used to update stores connected to an account. 2212 Messaging The Post transaction is used by one Mesh Service to 2213 transfer a message from one of its users to a different Mesh 2214 Service serving one of the recipients. 2216 Publication The Publish, Claim and PollClaim transactions are used 2217 to publish and retrieve data objects through an account. 2219 Cryptographic The Operate transaction requests that the service 2220 performs a cryptographic operation on behalf of the account. This 2221 is used to provide execution of threshold operations on behalf of 2222 the account holder for both internal and external users. 2224 Future versions of the Mesh Service Protocol may support additional 2225 transactions to support features such as providing DNS resolution. 2227 6.3.1. Protocol Interactions 2229 Every Mesh Service Protocol transaction consists of a single request 2230 from a Mesh client followed by a single response. Requests and 2231 responses are authenticated and encrypted under a key established 2232 between the client and the service. This application layer 2233 enhancement is in addition to any transport layer enhancement that 2234 may be employed (e.g. TLS). 2236 Mesh Service Protocol messages may be exchanged through any binding 2237 advertised by the service by means of the Hello transaction. 2238 Currently only one binding is defined, mapping Mesh requests and 2239 responses to the content data of HTTP POST requests and responses 2240 layers over a TLS transport. 2242 While the use of up to three layers of encryption may be regarded as 2243 excessive, each layer provides separate protections: 2245 Transport Layer Provides confidentiality for metadata and limited 2246 traffic analysis protections. 2248 Application Layer Encryption and authentication of requests and 2249 responses using keys bound to the specific device and service 2250 performing the interaction provides the basis for access control. 2252 Data Layer Encryption of stored data (catalog data, device 2253 activations, etc.) provides end to end security between the 2254 devices connected to the account. 2256 6.4. The Access Catalog 2258 The Access Catalog of a Mesh account is the only catalog whose 2259 payload contents are readable by the service. This is necessary 2260 because the catalog provides the sole source for the authorization 2261 component of the access control policy for the account. 2263 Each entry in the catalog specifies an operation that the service 2264 will perform when it receives a request that is authenticated and 2265 authorized by the access control policy specified in the entry. 2266 Operations include: 2268 Service Provision Account operations such as operations on stores 2269 (Status, Download, Transact) require that the client be 2270 authenticated by means of an authentication key that has a 2271 matching entry in the Access catalog that authorizes the 2272 operation. 2274 Inbound Message Filtering Messages received by the service that 2275 match the specified criteria will be appended to the inbound 2276 message spool. 2278 Threshold Key Generation Performs a threshold key splitting 2279 operation of a private key held by the service and encrypts one 2280 part under a key known only to the service and encrypts the other 2281 under a public key specified by the party making the request. 2283 Key Agreement Performs a key agreement operation on a private key 2284 held by the service. This may be used as a component in a 2285 threshold key agreement scheme. 2287 Signature Performs a signature operation on a private key held by 2288 the service. This may be used as a component in a threshold 2289 signature scheme. 2291 These operations provide the vocabulary from which a Threshold Key 2292 Infrastructure is built. Keys that are bound to a service using 2293 threshold techniques can only be applied with the co-operation of 2294 that service. 2296 6.5. Mesh Messaging Protocol 2298 Mesh devices connected to an account interact with the Mesh Service 2299 through the Mesh Service protocol. Mesh devices interact with other 2300 Mesh devices through the Mesh Messaging Protocols, each of which 2301 provides a distinct application functionality: 2303 * Connection Protocol 2305 * Confirmation Protocol 2307 * Contact Exchange Protocol 2309 Each of these protocols is described in depth in the Mesh Protocol 2310 Reference [draft-hallambaker-mesh-protocol]. 2312 Mesh Messages provide a means of communication between Mesh Service 2313 Accounts with capabilities that are not possible or poorly supported 2314 in traditional SMTP mail messaging: 2316 * End-to-end confidentiality and authentication by default. 2318 * Abuse mitigation by applying access control to every inbound and 2319 outbound message. 2321 * End-to-end secure group messaging. 2323 * Transfer of exceptionally large data sets (Terabytes). 2325 Note that although Mesh Messaging is designed to facilitate the 2326 transfer of very large data sets, the size of Mesh Messages 2327 themselves is severely restricted. The current default maximum size 2328 being 64 KB. This approach allows Mesh 2330 In addition, the platform anticipates but does not currently support 2331 additional cryptographic security capabilities: 2333 * Traffic analysis resistance using mix networks (Chaum). 2335 * Simultaneous contract binding using fair contract signing 2336 (Micali). 2338 While these capabilities might in time cause Mesh Messaging to 2339 replace SMTP, this is not a near term goal. The short-term goal of 2340 Mesh Messaging is to support the Contact Exchange and Confirmation 2341 applications. 2343 Two important classes of application that are not currently supported 2344 directly are payments and presence. While prototypes of these 2345 applications have been considered, it is not clear if these are best 2346 implemented as special cases of the Confirmation and Contact Exchange 2347 applications or as separate applications in their own right. 2349 Messages exchanged between Mesh Users MUST be mediated by a Mesh 2350 Service for both sending and receipt. This 'four corner' pattern 2351 permits ingress and egress controls to be enforced on the messages 2352 and that every message is properly recorded in the appropriate 2353 spools. 2355 (Artwork only available as svg: No external link available, see 2356 draft-hallambaker-mesh-architecture-19.html for artwork.) 2358 Figure 10: Four Corner Messaging Model 2360 For example, to send a message to Alice, Bob posts it to one of the 2361 Mesh Services connected to the Mesh Account from which the message is 2362 to be sent. The Mesh Service checks to see that both the message and 2363 Bob's pattern of behavior comply with their acceptable use policy and 2364 if satisfactory, forwards the message to the receiving service 2365 example.com. 2367 (Artwork only available as svg: No external link available, see 2368 draft-hallambaker-mesh-architecture-19.html for artwork.) 2370 Figure 11: Performing Access Control on Outbound Messages 2372 The receiving service uses the recipient's contact catalog and other 2373 information to determine if the message should be accepted. If 2374 accepted, the message is added to the recipient's inbound message 2375 spool to be collected by her device(s) when needed. 2377 (Artwork only available as svg: No external link available, see 2378 draft-hallambaker-mesh-architecture-19.html for artwork.) 2380 Figure 12: Performing Access Control on Inbound Messages 2382 For efficiency and to limit the scope for abuse, all inbound Mesh 2383 Messages are subject to access control and limited in size to 32KB or 2384 less. This limit has proved adequate to support transfer of complex 2385 control messages and short content messages. Transfer of data 2386 objects of arbitrary size may be achieved by sending a control 2387 message containing a URI for the main content which may then be 2388 fetched using a protocol such as HTTP. 2390 This approach makes transfers of exceptionally large data sets (i.e. 2391 multiple Terabytes) practical as the 'push' phase of the protocol is 2392 limited to the transfer of the initial control message. The bulk 2393 transfer is implemented as a 'pull' protocol allowing support for 2394 features such as continuous integrity checking and resumption of an 2395 interrupted transfer. 2397 6.6. Using the Mesh with Applications 2399 The Mesh provides an infrastructure for supporting existing Internet 2400 security applications and a set security features that may be used to 2401 build new ones. 2403 For example, Alice uses the Mesh to provision and maintain the keys 2404 she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the 2405 credential catalog for end-to-end secure management of the usernames 2406 and passwords for her Web browsing and other purposes: 2408 (Artwork only available as svg: No external link available, see 2409 draft-hallambaker-mesh-architecture-19.html for artwork.) 2411 Figure 13: Each of Alice's devices have access to the shared 2412 context of her personal account. 2414 The Mesh design is highly modular allowing components that were 2415 originally designed to support a specific requirement within the Mesh 2416 to be applied generally. 2418 6.6.1. Future Applications 2420 Since a wide range of network applications may be reduced to 2421 synchronization of sets and lists, the basic primitives of Catalogs 2422 and Spools may be applied to achieve end-to-end security in an even 2423 wider variety of applications. 2425 For example, a Spool may be used to maintain a mailing list, track 2426 comments on a Web forum or record annotations on a document. 2427 Encrypting the sequence entries under a multi-party encryption group 2428 allows such communications to be shared with a group of users while 2429 maintaining full end-to-end security and without requiring every 2430 party writing to the spool to know the public encryption key of every 2431 recipient. 2433 Another interesting possibility is the use of DARE Sequences as a 2434 file archive mechanism. A single signature on the final Merkle Tree 2435 digest value would be sufficient to authenticate every file in the 2436 archive. Updates to the archive might be performed using the same 2437 sequence synchronization primitives provided by a Mesh Service. This 2438 approach could afford a robust, secure, and efficient mechanism for 2439 software distribution and update. 2441 7. Security Considerations 2443 The security considerations for use and implementation of Mesh 2444 services and applications are described in the Mesh Security 2445 Considerations guide [draft-hallambaker-mesh-security]. 2447 8. IANA Considerations 2449 This document does not contain actions for IANA 2451 9. Acknowledgements 2453 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 2454 Alden, Michael Richardson. 2456 Appendix D: Outstanding Issues 2458 The following issues need to be addressed. 2460 +==========+====================================+ 2461 | Issue | Description | 2462 +==========+====================================+ 2463 | Newlines | Make handling of newlines in shell | 2464 | | commands consistent, sometimes | 2465 | | additional newlines are inserted. | 2466 +----------+------------------------------------+ 2467 | Recovery | Expand explanation and example to | 2468 | | show applications being recovered. | 2469 +----------+------------------------------------+ 2470 | Unread | Messages are not being correctly | 2471 | Bug | marked as read causing spurious | 2472 | | error messages. | 2473 +----------+------------------------------------+ 2475 Table 1 2477 10. Normative References 2479 [draft-hallambaker-jsonbcd] 2480 Hallam-Baker, P., "Binary Encodings for JavaScript Object 2481 Notation: JSON-B, JSON-C, JSON-D", Work in Progress, 2482 Internet-Draft, draft-hallambaker-jsonbcd-21, 5 August 2483 2021, . 2486 [draft-hallambaker-mesh-callsign] 2487 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Mesh 2488 Callsign Service", Work in Progress, Internet-Draft, 2489 draft-hallambaker-mesh-callsign-01, 23 October 2021, 2490 . 2493 [draft-hallambaker-mesh-cryptography] 2494 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 2495 Cryptographic Algorithms", Work in Progress, Internet- 2496 Draft, draft-hallambaker-mesh-cryptography-08, 5 August 2497 2021, . 2500 [draft-hallambaker-mesh-dare] 2501 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2502 At Rest Encryption (DARE)", Work in Progress, Internet- 2503 Draft, draft-hallambaker-mesh-dare-13, 20 September 2021, 2504 . 2507 [draft-hallambaker-mesh-developer] 2508 Hallam-Baker, P., "Mathematical Mesh: Reference 2509 Implementation", Work in Progress, Internet-Draft, draft- 2510 hallambaker-mesh-developer-10, 27 July 2020, 2511 . 2514 [draft-hallambaker-mesh-platform] 2515 Hallam-Baker, P., "Mathematical Mesh: Platform 2516 Configuration", Work in Progress, Internet-Draft, draft- 2517 hallambaker-mesh-platform-06, 27 July 2020, 2518 . 2521 [draft-hallambaker-mesh-protocol] 2522 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 2523 Reference", Work in Progress, Internet-Draft, draft- 2524 hallambaker-mesh-protocol-10, 20 September 2021, 2525 . 2528 [draft-hallambaker-mesh-rud] 2529 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Reliable 2530 User Datagram", Work in Progress, Internet-Draft, draft- 2531 hallambaker-mesh-rud-00, 5 August 2021, 2532 . 2535 [draft-hallambaker-mesh-schema] 2536 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema 2537 Reference", Work in Progress, Internet-Draft, draft- 2538 hallambaker-mesh-schema-08, 5 August 2021, 2539 . 2542 [draft-hallambaker-mesh-security] 2543 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IX Security 2544 Considerations", Work in Progress, Internet-Draft, draft- 2545 hallambaker-mesh-security-08, 20 September 2021, 2546 . 2549 [draft-hallambaker-mesh-udf] 2550 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 2551 Data Fingerprint.", Work in Progress, Internet-Draft, 2552 draft-hallambaker-mesh-udf-14, 20 September 2021, 2553 . 2556 [draft-hallambaker-threshold] 2557 Hallam-Baker, P., "Threshold Modes in Elliptic Curves", 2558 Work in Progress, Internet-Draft, draft-hallambaker- 2559 threshold-06, 5 August 2021, 2560 . 2563 [draft-hallambaker-web-service-discovery] 2564 Hallam-Baker, P., "DNS Web Service Discovery", Work in 2565 Progress, Internet-Draft, draft-hallambaker-web-service- 2566 discovery-06, 5 August 2021, 2567 . 2570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2571 Requirement Levels", BCP 14, RFC 2119, 2572 DOI 10.17487/RFC2119, March 1997, 2573 . 2575 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2576 (TLS) Protocol Version 1.2", RFC 5246, 2577 DOI 10.17487/RFC5246, August 2008, 2578 . 2580 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 2581 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2582 2014, . 2584 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2585 (HTTP/1.1): Semantics and Content", RFC 7231, 2586 DOI 10.17487/RFC7231, June 2014, 2587 . 2589 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2590 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2591 2015, . 2593 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 2594 RFC 7516, DOI 10.17487/RFC7516, May 2015, 2595 . 2597 11. Informative References 2599 [draft-hallambaker-mesh-trust] 2600 Hallam-Baker, P., "Mathematical Mesh 3.0 Part X: The Trust 2601 Mesh", Work in Progress, Internet-Draft, draft- 2602 hallambaker-mesh-trust-09, 5 August 2021, 2603 . 2606 [draft-irtf-cfrg-frost] 2607 Komlo, C., Goldberg, I., and T. Wilson-Brown, "Two-Round 2608 Threshold Signatures with FROST", Work in Progress, 2609 Internet-Draft, draft-irtf-cfrg-frost-01, 11 August 2021, 2610 .