idnits 2.17.1 draft-hallambaker-mesh-architecture-15.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 (2 November 2020) is 1269 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 2 November 2020 5 Expires: 6 May 2021 7 Mathematical Mesh 3.0 Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-15 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 6 May 2021. 46 Copyright Notice 48 Copyright (c) 2020 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. The Mesh as platform . . . . . . . . . . . . . . . . . . 12 70 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.6. Enterprise Deployment . . . . . . . . . . . . . . . . . . 13 72 4. User Experience . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1. Creating a Mesh Account . . . . . . . . . . . . . . . . . 13 74 4.1.1. Encrypting and Decrypting files. . . . . . . . . . . 14 75 4.1.2. Catalogs . . . . . . . . . . . . . . . . . . . . . . 15 76 4.2. Adding devices . . . . . . . . . . . . . . . . . . . . . 16 77 4.2.1. Decrypting files on the new device . . . . . . . . . 18 78 4.2.2. Applications . . . . . . . . . . . . . . . . . . . . 19 79 4.3. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 20 80 4.3.1. Contact exchange . . . . . . . . . . . . . . . . . . 21 81 4.3.2. Confirmation service . . . . . . . . . . . . . . . . 22 82 4.4. Encryption Groups . . . . . . . . . . . . . . . . . . . . 24 83 4.5. Escrow and Recovery . . . . . . . . . . . . . . . . . . . 25 84 4.6. Future Applications . . . . . . . . . . . . . . . . . . . 26 85 4.6.1. Synchronous Messaging . . . . . . . . . . . . . . . . 26 86 4.6.2. Social Media . . . . . . . . . . . . . . . . . . . . 26 87 5. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 26 88 5.1. Best Practice by Default . . . . . . . . . . . . . . . . 27 89 5.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 28 90 5.3. Threshold Decryption . . . . . . . . . . . . . . . . . . 28 91 5.4. Threshold Key Generation . . . . . . . . . . . . . . . . 29 92 5.5. Threshold Signature . . . . . . . . . . . . . . . . . . . 29 93 5.6. Data At Rest Encryption . . . . . . . . . . . . . . . . . 29 94 5.6.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 30 95 5.6.2. Dare Container . . . . . . . . . . . . . . . . . . . 30 96 5.7. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 31 97 5.7.1. Friendly Names . . . . . . . . . . . . . . . . . . . 31 98 5.7.2. Encrypted Authenticated Resource Locators . . . . . . 32 99 5.7.3. Secure Internet Names . . . . . . . . . . . . . . . . 33 100 5.8. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 33 101 6. Mesh Architecture . . . . . . . . . . . . . . . . . . . . . . 34 102 6.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 6.1.1. Account . . . . . . . . . . . . . . . . . . . . . . . 35 104 6.1.2. Device . . . . . . . . . . . . . . . . . . . . . . . 36 105 6.1.3. Service . . . . . . . . . . . . . . . . . . . . . . . 38 106 6.2. Stores . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 6.2.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 39 108 6.2.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 40 109 6.3. Mesh Service Protocol . . . . . . . . . . . . . . . . . . 40 110 6.3.1. Protocol Interactions . . . . . . . . . . . . . . . . 41 111 6.4. The Threshold Catalog . . . . . . . . . . . . . . . . . . 41 112 6.5. Mesh Messaging Protocol . . . . . . . . . . . . . . . . . 42 113 6.6. Using the Mesh with Applications . . . . . . . . . . . . 44 114 6.6.1. Future Applications . . . . . . . . . . . . . . . . . 45 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 118 10. Normative References . . . . . . . . . . . . . . . . . . . . 45 119 11. Informative References . . . . . . . . . . . . . . . . . . . 48 121 1. Introduction 123 The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure (TKI) 124 that uses cryptography to make computers easier to use. This 125 document describes version 3.0 of the Mesh architecture and 126 protocols. 128 In 1977, Public Key cryptography laid out a powerful proposition: If 129 Alice and Bob have private keys on their devices and each knows the 130 public key of the other, Alice and Bob can communicate with 131 confidentiality and integrity. The realization of this proposition 132 at Internet scale was vested in a technology called Public Key 133 Infrastructure (PKI) whose principal function is to provide a 134 trustworthy means by which Alice and Bob can discover each other's 135 public key. 137 Yet despite the power of PKI, Internet security remains a work in 138 progress. While PKI has proved an effective means of authenticating 139 services to users, attempts to apply PKI to the equally important 140 task of authenticating users to services and securing data at rest 141 have been confined to the margins. One critical reason for that 142 failure is that _Public_ Key Infrastructure has only provided 143 effective tools for managing _public_ keys. If we are to achieve 144 comprehensive Internet security, we must provide every user with the 145 ability to manage private keys across their devices with zero effort 146 on their part. 148 Threshold cryptography is a sub-field of public key cryptography that 149 defines operations on cryptographic keys, including operations on 150 private keys. Threshold cryptography allows Key generation and key 151 use operations may be split between multiple devices. These tools 152 make zero effort management of private keys practical. 154 The Mesh is a TKI that addresses the three principal concerns that 155 have proved obstacles to the use of end-to-end security in computer 156 applications: 158 * Device management. 160 * Exchange of trusted credentials. 162 * Application configuration management. 164 The infrastructure developed to address these original motivating 165 concerns can be used to facilitate deployment and use of existing 166 security protocols (OpenPGP, S/MIME, SSH) and as a platform for 167 building end-to-end secure network applications. Current Mesh 168 applications include: 170 * Multi-factor authentication and confirmation 172 * Credential management 174 * Bookmark/Citation management 176 * Task and workflow management 178 A core principle of the design of the Mesh is _autonomy_. That is 179 each user has full control over their digital environment and is 180 their own source of authority. They may choose to delegate that 181 authority to another to act on their behalf (i.e. a Trusted Third 182 Party) and they may choose to surrender parts of that authority to 183 others (e.g. an employer) without surrendering their autonomy. 184 Delegation of authority is always for limited times and limited 185 purposes. 187 Thus, from the user's point of view, the Mesh is divided into two 188 parts: The part of the Mesh that belongs to them and everything else. 189 As with the Internet, which is a network of networks, a Mesh of 190 Meshes has certain properties that are similar to those of its 191 constituent parts and some that are quite different. 193 This document is not normative. It provides an overview of the Mesh 194 comprising a description of the architecture, and a discussion of 195 typical use cases and requirements. The remainder of the document 196 series provides a summary of the principal components of the Mesh 197 architecture and their relationship to each other. 199 Normative descriptions of the individual Mesh encodings, data 200 structures and protocols are provided in separate documents 201 addressing each component in turn. 203 The currently available Mesh document series comprises: 205 I. Architecture (This document.) Provides an overview of the Mesh 206 as a system and the relationship between its constituent parts. 208 II. Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. Describe 209 s the UDF format used to represent cryptographic nonces, keys and 210 content digests in the Mesh and the use of Encrypted Authenticated 211 Resource Locators (EARLs) and Strong Internet Names (SINs) that 212 build on the UDF platform. 214 III. Data at Rest Encryption [draft-hallambaker-mesh-dare]. Describ 215 es the cryptographic message and append-only sequence formats used 216 in Mesh applications and the Mesh Service protocol. 218 IV. Schema Reference [draft-hallambaker-mesh-schema]. Describes the 219 syntax and semantics of Mesh Profiles, Container Entries and Mesh 220 Messages and their use in Mesh Applications. 222 V. Protocol Reference [draft-hallambaker-mesh-protocol]. Describes 223 the Mesh Service Protocol. 225 VI Mesh Discovery Service [draft-hallambaker-mesh-discovery]. Descri 226 bes the Mesh Discovery Service that supports mapping of Mesh names 227 to the corresponding Mesh Service Provider. 229 VII. Security Considerations [draft-hallambaker-mesh-security] Desc 230 ribes the security considerations for the Mesh protocol suite. 232 VIII Cryptographic Algorithms 233 [draft-hallambaker-mesh-cryptography]. Describes the recommended and 234 required algorithm suites for Mesh applications and the 235 implementation of the multi-party cryptography techniques used in 236 the Mesh. 238 The following documents describe technologies that are used in the 239 Mesh but do not form part of the Mesh specification suite: 241 IX. The Trust Mesh [draft-hallambaker-mesh-trust]. Describes the 242 social work factor metric used to evaluate the effectiveness of 243 different approaches to exchange of credentials between users and 244 organizations in various contexts and argues for a hybrid approach 245 taking advantage of direct trust, Web of Trust and Trusted Third 246 Party models to provide introductions. 248 JSON-BCD Encoding [draft-hallambaker-jsonbcd]. Describes extensions 249 to the JSON serialization format to allow direct encoding of 250 binary data (JSON-B), compressed encoding (JSON-C) and extended 251 binary data encoding (JSON-D). Each of these encodings is a 252 superset of the previous one so that JSON-B is a superset of JSON, 253 JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C. 255 DNS Web Service Discovery 256 [draft-hallambaker-web-service-discovery]. Describes the means by 257 which prefixed DNS SRV and TXT records are used to perform 258 discovery of Web Services. 260 Threshold Modes in Elliptic Curves [draft-hallambaker-threshold]. De 261 scribes threshold key generation and key agreement operations for 262 the Ed25519, Ed448, X25519 and X448 elliptic curves. 264 Threshold Signatures in Elliptic Curves 265 [draft-hallambaker-threshold-sigs]. Describes creation of threshold 266 signatures using the Ed25519 and Ed448 elliptic curves. 268 The following documents describe aspects of the Mesh Reference 269 implementation: 271 Mesh Developer [draft-hallambaker-mesh-developer]. Describes the 272 reference code distribution license terms, implementation status 273 and currently supported functions. 275 Mesh Platform [draft-hallambaker-mesh-platform]. Describes how 276 platform specific functionality such as secure key storage and 277 trustworthy computing features are employed in the Mesh. 279 2. Definitions 281 This section presents the related specifications and standards on 282 which the Mesh is built, the terms that are used as terms of art 283 within the Mesh protocols and applications and the terms used as 284 requirements language. 286 2.1. Related Specifications 288 Besides the documents that form the Mesh core, the Mesh makes use of 289 many existing Internet standards, including: 291 Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic 292 algorithms for Mesh implementations are specified in 293 [draft-hallambaker-mesh-cryptography]. 295 In addition, Mesh Devices used to administer non-Mesh applications 296 must support the cryptographic algorithm suites specified by the 297 application. 299 Transport All Mesh Services make use of multiple layers of security. 300 Protection against traffic analysis and metadata attacks are 301 provided by use of Transport Layer Security [RFC5246]. At 302 present, the HTTP/1.1 [RFC7231] protocol is used to provide 303 framing of transaction messages. 305 Encoding All Mesh protocols and data structures are expressed in the 306 JSON data model and all Mesh applications accept data in standard 307 JSON encoding [RFC7159]. The JOSE Signature [RFC7515] and 308 Encryption [RFC7516] standards are used as the basis for object 309 signing and encryption. 311 2.2. Defined Terms 313 TBS 315 2.3. Requirements Language 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 319 document are to be interpreted as described in RFC 2119 [RFC2119]. 321 2.4. Implementation Status 323 The implementation status of the reference code base is described in 324 the companion document [draft-hallambaker-mesh-developer]. 326 The examples in this document were created on 11/2/2020 4:47:04 PM. 327 Out of 51 examples, 16 failed. 329 3. Requirements 331 The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure that 332 uses cryptography to make computers easier to use. 334 For several decades, it has been widely noted that most users are 335 either unwilling or unable to make even the slightest efforts to 336 protect their security, still less those of other parties. Yet 337 despite this observation being widespread, the efforts of the IT 338 security community have largely focused on changing this user 339 behavior rather that designing applications that respect it. Real 340 users have real work to do and have neither the time nor the 341 inclination to use tools that will negatively impact their 342 performance. 344 The Mesh is based on the principle that if the Internet is to be 345 secure, if must become effortless to use applications securely. 346 Rather than beginning the design process by imagining all the 347 possible modes of attack and working out how to address these as best 348 as possible without unnecessary inconvenience to the user, we must 349 reverse the question and ask how much security can be provided 350 without requiring any effort whatsoever from the user. This 351 principle is called*Zero Effort Security*. 353 Today's technology requires users to put their trust in an endless 354 variety of devices, software and services they cannot fully 355 understand let alone control. Even the humble television of the 20th 356 century has been replaced by a 'smart' TV with 15 million lines of 357 code whose undeclared capabilities may well include placing the room 358 in which it is placed under continuous audio and video surveillance. 360 Every technology deployment by necessity requires some degree of 361 trust on the owner/user's part. But this trust should not compromise 362 the user's autonomy. Delegation of trust should be limited and 363 subject to accountability. If manufacturers continue to fail in this 364 regard, they risk a backlash in which users seek to restore their 365 rights through litigation, legislation or worst of all, simply not 366 buying more technology that they have learned to distrust through 367 their own experience. 369 The Mesh is based on the principle of radical distrust, that is, if a 370 party is capable of defecting, we assume that they will. As the 371 Russian proverb goes: ???????, ?? ????????: trust, but verify. 373 In the 1990s, the suggestion that 'hackers' might seek to make 374 financial gains from their activities was denounced as 'fear- 375 mongering'. The suggestion that email or anonymous currencies might 376 be abused received a similar response. Today malware, ransomware and 377 spam have become so ubiquitous that they are no longer news unless 378 the circumstances are particularly egregious. In 1949, Edward A. 379 Murphy Jr. proposed his now eponymous law which states, 'Anything 380 that can go wrong will go wrong'. We must now apply a similar 381 principle to Internet security: 'Anything that can be made to go 382 wrong is already being made to go wrong and will only get worse until 383 something is done to stop it.' 385 We must dispense with the notion that it is improper or impolite to 386 question the good faith of technology suppliers of any kind whether 387 they be manufacturers, service providers, software authors or 388 reviewers. Modern supply chains are complex, typically involving 389 hundreds if not thousands of potential points of deliberate or 390 accidental compromise. The technology provider who relies on the 391 presumption of good faith on their part risks serious damage to their 392 reputation when others assert that a capability added to their 393 product may have malign uses. 395 Radical distrust means that we apply the principles of least 396 principle and accountability at every level to the design of the 397 Mesh: 399 * Cryptographic keys installed in a product during manufacture are 400 only used for the limited purpose of putting that device under 401 control of the user. 403 * Cryptographic keys and assertions related to management of devices 404 are only visible to the user they belong to and are never exposed 405 to external parties. 407 * Mesh Accounts belong to and are under control of the user they 408 belong to and not the Mesh Service provider which the user can 409 change at will with minimal inconvenience. 411 * Mesh Services do not have access to the plaintext of any Mesh 412 Messages or Mesh Catalog data except for the threshold catalog 413 used by the service as the source of access control policy. 415 * All Mesh Messages are subject to access control by both the 416 inbound and outbound Mesh Service to mitigate messaging abuse. 418 Security is risk management and not the elimination of all 419 possibility of any risk. Radical distrust means that we raise the 420 bar for attackers to the point where for most attackers the risk is 421 greater than the reward. It does not demand that we immediately 422 address every issue with perfection or delay deployment of 423 technologies that are capable of controlling _many_ risks until we 424 have achieved the control of _every_ risk. 426 In addition to distrusting technology providers the Mesh Architecture 427 allows the user to limit the degree of trust they place in 428 themselves. In the real world, devices are lost or stolen, passwords 429 and activation codes are forgotten, natural or man-made catastrophes 430 cause property and data to be lost. The Mesh permits but does not 431 require use of escrow techniques that allow recovery from such 432 situations. 434 3.1. The Device Management Challenge 436 Existing PKIs were developed in an era when the 'personal computer' 437 was still coming into being. Only a small number of people owned a 438 computer and an even smaller number owned more than one. In these 439 circumstances, it arguably sufficed to provision a user with a single 440 private key on the single device they were likely to use. 442 Today, computers are ubiquitous and a typical home in the developed 443 world contains several hundred of which a dozen or more may have some 444 form of network access. The modern consumer faces a problem of 445 device management that is considerably more complex than the IT 446 administrator of a small business might have faced in the 1990s but 447 without any of the network management tools such an administrator 448 would expect to have available. 450 One important consequence of the proliferation of devices is that 451 end-to-end security is no longer sufficient. To be acceptable to 452 users, a system must be ends-to-ends secure. That is, a user must be 453 able to read their encrypted email message on their laptop, tablet, 454 phone, or watch with exactly the same ease of use as if the mail were 455 unencrypted. A cryptographic security control that impedes the user 456 is a control that is not going to be used. 458 Each personal Mesh contains a device catalog in which the 459 cryptographic credentials and device specific application 460 configurations for each connected device are stored. 462 Management of the device catalog is restricted to a subset of devices 463 that the owner of the Mesh has specifically authorized for that 464 purpose as administration devices. Only a device with access to a 465 duly authorized administration key can add or remove devices from a 466 personal Mesh. 468 3.2. Exchange of trusted credentials. 470 One of the most challenging, certainly the most contentious issues in 471 PKI is the means by which cryptographic credentials are published and 472 validated. Here there are two different challenges. 474 Developing an infrastructure that provides a mapping to a 475 cryptographic key from a name that serves no other purpose than 476 identifying the key is relatively easy. Developing an infrastructure 477 that maps existing names with semantics that are already established 478 is considerably harder. 480 The Mesh does not attempt to impose criteria for accepting 481 credentials as valid as no such set of criteria can be comprehensive. 482 Rather the Mesh provides an internal trust infrastructure that makes 483 use of a _direct trust_ model similar to that of PGP fingerprints to 484 which external names may be mapped using whatever validation criteria 485 users consider are appropriate to the purpose for which they intend 486 to use them. 488 The principles of providing extended trust management in the Mesh are 489 further described in [draft-hallambaker-mesh-trust]. 491 3.3. Application configuration management 493 Configuration of cryptographic applications is typically worse than 494 an afterthought. Configuration of one popular mail user agent to use 495 S/MIME security requires 17 steps to be performed using four separate 496 application programs. And since S/MIME certificates expire, the user 497 is required to repeat these steps every few years. Contrary to the 498 public claims made by one major software vendor it is not necessary 499 to perform 'usability testing' to recognize abject stupidity. 501 Rather than writing down configuration steps and giving them to the 502 user, we should turn them into code and give them to a machine. 503 Users should never be required to do the work of the machine. Nor 504 should any programmer be allowed to insult the user by casting their 505 effort aside and requiring it to be re-entered. 507 While most computer professionals who are required to do such tasks 508 on a regular basis will create a tool for the purpose, most users do 509 not have that option. And of those who do write their own tools, 510 only a few have the time and the knowledge to do the job without 511 introducing security vulnerabilities. 513 3.4. The Mesh as platform 515 Meeting the core objectives of the Mesh required new naming, 516 communication and cryptographic capabilities provided to be 517 developed. These capabilities may in turn be used to develop new 518 end-to-end secure applications. 520 For example, the Mesh Catalogs used to maintain collections of device 521 descriptions, bookmarks, credentials, etc. might be used in an 522 electronic records infrastructure to maintain chain of custody of 523 digital evidence. 525 3.5. Security 527 The Mesh is designed to provide the greatest practical level of 528 security that does not detract from the user experience. The usual 529 CIA triad is considered: 531 Confidentiality The confidentiality of user content should be 532 protected at all times and against all unauthorized parties 533 including their MSP. 535 Reasonable efforts should be taken to protect user data against 536 traffic analysis and metadata attacks. It is not necessary to 537 consider disclosure of this information to MSPs. Metadata must be 538 shielded from external parties but controls to prevent traffic 539 analysis may be left to implementers. 541 Integrity The design should consider unauthorized modification of 542 data to be at least as serious as disclosure. 544 Availability The design should consider loss of data likely to be at 545 least as serious as disclosure. 547 In addition to protecting the user's data, the Mesh is designed to 548 protect the user's autonomy. While the use of any electronic device 549 or service entails a degree of trust, the user should have the right 550 to decide which devices and which service providers to trust and to 551 have the practical ability to revoke that trust at any time they 552 choose. 554 3.6. Enterprise Deployment 556 Development of PKI has traditionally focused on the needs of large 557 enterprises. The Mesh is focused on the individual user. While this 558 change of focus is in part a recognition of the need to reverse the 559 traditional bias, it is also a recognition of the fact that we must 560 understand the needs of the individual user before attempting to 561 understand the additional needs of an enterprise IT department 562 serving a large number of users. 564 4. User Experience 566 This section describes the Mesh in use. These _use cases_ described 567 here are re-visited in the companion Mesh Schema Reference 568 [draft-hallambaker-mesh-schema] and Mesh Protocol Reference 569 [draft-hallambaker-mesh-protocol] with further details and additional 570 examples. 572 For clarity and compactness of exposition, these use cases are 573 illustrated using the command line tool _meshman_, a tool that makes 574 the cryptographic operations explicit. This does not represent the 575 ideal user experience in which Zero-effort security is achieved. 576 Such a user experience requires that the Mesh operations be 577 seamlessly integrated into the user's applications so that instead of 578 using the meshman tool to encrypt or decrypt document, the word 579 processor application itself would be extended to read and write 580 documents encrypted in the DARE format. 582 4.1. Creating a Mesh Account 584 From the user's perspective, their personal Mesh consists of a 585 collection of devices that communicate seamlessly and securely 586 through a Mesh account serviced by a Mesh Service Provider (MSP). 588 (Artwork only available as svg: No external link available, see 589 draft-hallambaker-mesh-architecture-15.html for artwork.) 591 Figure 1 593 As with an email service provider, the user is only likely to be 594 aware of their interactions with their MSP in the case of a service 595 interruption. As far as the user is concerned the data is replicated 596 across their devices automatically unless there is a problem. 598 While the term 'account' is used because it is the term a user is 599 familiar with that most closely describes its functions, Mesh 600 accounts are different from traditional Internet accounts in one 601 important respect: In order to realize the principle of 'autonomy', 602 Mesh accounts are created by and _belong to_ the user and not the 603 service provider. Should a serious problem occur, a user may opt to 604 change their MSP. But unlike a changing an SMTP email provider, this 605 change is made seamless and cost free. 607 Another important difference between the Mesh and SMTP is that all 608 Mesh data is encrypted end to end. The MSP does not have access to 609 any user content and does not have access to any user meta-data 610 except that which is strictly necessary to service the account. 612 The only Mesh catalogs associated with a Mesh account that can be 613 read by an MSP are the Access Catalog which serves as the basis for 614 specifying and enforcing access control policy on the resources 615 associated with the account and the Publications Catalog which is an 616 index of encrypted data published through the account. 618 To create a Mesh account, the user need only specify the account name 619 and the initial MSP: 621 The user specifies the initial account address to be used 622 (alice@example.com). Use of this address is of course dependent on 623 authorization by the Mesh Service Provider (example.com) and is 624 likely to require authentication and possibly payment. 626 Alice> account create alice@example.com 627 Account=MCQ4-CSYK-2LAY-3XXW-72CL-6P65-X6CQ 629 The command returns the value of Alice's Mesh Account fingerprint . 630 This value is used as a unique identifier that is cryptographically 631 bound to the signature key used to authenticate the account profile. 633 Note that the user does not specify the cryptographic algorithms to 634 use. Choice of cryptographic algorithm is primarily the concern of 635 the protocol designer, not the user. The only circumstance in which 636 users would normally be involved in algorithm selection is when there 637 is a transition in progress from one algorithm suite to another. 639 4.1.1. Encrypting and Decrypting files. 641 Having created an account, Alice can use it to encrypt files and 642 decrypt them on the same machine. 644 Alice encrypts the text file plaintext.txt to create an encrypted 645 version readable only by Alice: 647 Alice> type plaintext.txt 648 This is a test 649 Alice> dare encode plaintext.txt ciphertext.dare /encrypt ^ 650 alice@example.com 651 Alice> dare verify ciphertext.dare 652 File: ciphertext.dare 653 Bytes: 0 654 Encryption Algorithm: A256CBC 655 Recipient: MBNX-5MOX-L2P6-6B33-QAU4-V3Y3-3ZM4 656 Digest Algorithm: S512 657 Payload Digest: 659 Alice can recover the file at any time using the decryption command: 661 Alice> dare decode ciphertext.dare plaintext1.txt 662 Alice> type plaintext1.txt 663 This is a test 665 Although the encrypted file can be accessed by Alice with precisely 666 the same ease as the plaintext version, the contents of the encrypted 667 file are not readable by any other user of the machine unless Alice 668 explicitly grants access. The encrypted file may be stored on a 669 shared drive, cloud file system or removable storage without 670 disclosing the contents. 672 While encrypting and decrypting files using a tool provides the 673 desired functionality, it does not meet our objectives for usability. 674 These capabilities should be integrated into applications or the 675 platform itself. 677 4.1.2. Catalogs 679 Every Mesh account is created with a set of catalogs and spools. For 680 example, the bookmarks catalog maintains a list of the user's Web 681 bookmarks. The credentials catalog maintains a list of the user's 682 usernames and passwords for the various network services they use. 683 As with the file encryption example, these capabilities are clearly 684 going to be most effective when incorporated into the user's 685 applications, (i.e. their Web browser). 687 Alice adds the username and password she uses to access her weather 688 service account to her credentials catalog: 690 Alice> password add ftp.example.com alice1 password 691 alice1@ftp.example.com = [password] 692 Alice> password add www.example.com alice@example.com newpassword 693 alice@example.com@www.example.com = [newpassword] 694 As with all Mesh Catalogs, the catalog data is encrypted and cannot 695 be accessed by any unauthorized party including the Mesh Service 696 Provider. 698 If needed, she can retrieve the credentials from the catalog by 699 specifying the network resource to which access is required: 701 Alice> password get ftp.example.com 702 alice1@ftp.example.com = [password] 704 This capability provides a means of preventing one of the most common 705 causes of enterprise password breach in which a system administrator 706 encodes the access credentials for a service into a script used to 707 access the service. A script containing a command to extract the 708 credentials from a Mesh catalog will only work for a user authorized 709 to access the credentials in the Mesh. 711 4.2. Adding devices 713 Computers have become ubiquitous and inexpensive. Most people living 714 in affluent countries interact with several dozen computer systems 715 every day. Every household appliance from the television to the 716 coffee pot has become or is in the process of becoming a computer. 717 It is this circumstance that has exposed the critical flaw in 718 traditional PKI: The lack of practical means of managing private keys 719 across multiple devices. 721 The Mesh allows users to connect all their devices together so that 722 they may be considered part of a single entity whose component parts 723 communicate and interact seamlessly and securely. 725 Although any type of network capable device may be connected to a 726 Mesh profile, some devices are better suited for use with certain 727 applications than others. Connecting an oven to a Mesh profile could 728 allow it to be controlled through entries to the user's recipe and 729 calendar catalogs and alert the user when the meal is ready but 730 attempting to use it to read emails or manage Mesh profiles. The 731 Mesh allows the principle of least privilege when connecting a device 732 granting precisely the set of capabilities required to perform its 733 intended function. 735 Multiple connection mechanisms are specified, each of which provides 736 strong mutual authentication. In each case, the connection request 737 must be approved by a device provisioned with the Mesh administration 738 privilege: 740 Direct The connection request is initiated on the device being 741 requested and approved on the administration device. 742 Authentication of the connection request is performed by comparing 743 witness values presented on the connecting device and the 744 administration device. 746 PIN A PIN code is generated on an administration device and passed 747 to the connecting device out of band. The connecting device 748 provides proof of knowledge of this PIN code when making the 749 connection request allowing an administration device to approve 750 the request automatically without further user interaction. 752 Dynamic QR This connection mechanism is a variation of the PIN 753 connection mechanism in which administration device presents the 754 PIN code value to the connecting device in the form of a QR code. 755 This allows a connecting device with a camera to connect with 756 minimal user effort. 758 Static QR This connection method is designed to support connection 759 of constrained IoT devices that lack a camera or display 760 capability. An administration device equipped with a camera reads 761 a static QR code printed on the device that provides the 762 information used to enable the administration device to establish 763 a local network connection (e.g. WiFi, Bluetooth, strobe, IR) 764 that can be used to complete the connection. 766 For example, Alice connects a second device using the direct 767 connection mechanism: 769 The connection request is initiated on the device being connected: 771 Alice2> device request alice@example.com 772 Device UDF = MCR5-EJWB-KRGF-3SYW-ASKC-DWUP-FIQQ 773 Witness value = RQUH-LNHP-XVR6-UHQ5-WSCZ-WCZC-Q5PK 775 Using her administration device, Alice gets a list of pending 776 requests. Seeing that there is a pending request matching the 777 witness value presented by the device, Alice accepts it: 779 Alice> message pending 780 MessageID: DGVB-YMZP-LJCN-XY3D-LGWE-2G33-WXFE 781 Connection Request:: 782 MessageID: DGVB-YMZP-LJCN-XY3D-LGWE-2G33-WXFE 783 To: From: 784 Device: MDJ2-URNT-WXPZ-5PLB-J3XM-MJK5-AEWG 785 Witness: DGVB-YMZP-LJCN-XY3D-LGWE-2G33-WXFE 786 MessageID: NBAC-LLBY-E4EU-7ZRF-I47O-ZYHZ-PBCW 787 Confirmation Request:: 788 MessageID: NBAC-LLBY-E4EU-7ZRF-I47O-ZYHZ-PBCW 789 To: alice@example.com From: console@example.com 790 Text: start 791 MessageID: NBKU-OVBZ-YZRN-FEB4-ARMW-VUVI-2JSG 792 Contact Request:: 793 MessageID: NBKU-OVBZ-YZRN-FEB4-ARMW-VUVI-2JSG 794 To: alice@example.com From: bob@example.com 795 PIN: AD6Q-2HLS-M3HL-MYNB-43SW-OXCM-QFSA 796 Alice> account sync /auto 797 ERROR - Cannot access a closed file. 798 Alice> device accept RQUH-LNHP-XVR6-UHQ5-WSCZ-WCZC-Q5PK 799 ERROR - Cannot access a closed file. 801 Alice can now synchronize her newly connected device to her account: 803 Alice2> device complete 805 These connection mechanisms are described in detail in the Mesh 806 Protocol Reference [draft-hallambaker-mesh-protocol]. 808 4.2.1. Decrypting files on the new device 810 Having connected a second device and granted it 'Web' rights, Alice 811 can use it to decrypt files and access her bookmark and password 812 catalogs in exactly the same fashion as the first. If a password is 813 changed on one device, all her connected devices receive the update. 815 For example, Alice can now decrypt the file she encrypted on her 816 first device and access her credential catalog from the new device: 818 Alice2> password get ftp.example.com 819 ERROR - No decryption key is available 820 Alice2> dare decode ciphertext.dare plaintext2.txt 821 ERROR - No decryption key is available 823 Should the new device be lost, stolen or simply broken, Alice can 824 prevent further use of the device to decrypt her data by 825 disconnecting it from her Mesh: 827 Alice disconnects the new device: 829 Alice> device delete TBS 830 ERROR - The feature has not been implemented 832 The device can no longer access the password catalog: 834 Alice2> dare decode ciphertext.dare plaintext2.txt 835 ERROR - No decryption key is available 837 The use of threshold decryption allows the Mesh Service Provider to 838 control the use of decryption by Alice's devices without having the 839 ability to decrypt the content itself. 841 4.2.2. Applications 843 Connected devices can also make use of connected applications for 844 which they are granted the necessary rights. 846 Alice creates an SSH profile within her Mesh on the administrative 847 device. 849 Missing example 1 851 After configuring an SSH server to accept her new SSH credential, she 852 can use any of her devices that has been granted the SSH right to 853 connect to it. 855 In this case Alice has chosen to use an SSH configuration in which a 856 single client key is shared across multiple devices. The Mesh is in 857 principle capable of supporting more sophisticated configurations in 858 which use of the client key is under control of a threshold service 859 and/or each device has its own individual private. Consideration of 860 these configuration modes is currently outside the scope of work for 861 the Mesh and is probably more usefully considered as part of an 862 effort to integrate Mesh functionality into the SSH system. This 863 would also allow support for features such as recording SSH server 864 key fingerprints in the Mesh Contacts catalog. 866 Alice could enable use of OpenPGP and S/MIME on her connected devices 867 that have been granted the "messaging" right in a similar way. All 868 the network and security configuration data required to use one of 869 her email accounts is stored in her Mesh applications catalog. The 870 Mesh client performs all the steps required to obtain and install CA 871 issued certificates. As with the SSH example, while it is quite 872 possible to support all the necessary functionality through the Mesh 873 alone, a better result is likely to be achieved by modifying the SMTP 874 email clients and Certificate Authority infrastructures. 876 4.3. Mesh Messaging 878 The Mesh Messaging system is a push messaging system analogous to 879 SMTP, but its purpose is limited to secure exchange of control plane 880 messages. This leads to some important differences: 882 * Every message is signed and end-to-end encrypted 884 * The only communication pattern supported is a four-corner model in 885 which users exchange messages through their respective MSPs. 887 * Every message is subject to access control at the inbound and 888 outbound MSP. 890 * Message content is limited to 32KB. 892 This size restriction ensures that exchange of Mesh Messages does not 893 impose an undue burden on the inbound and outbound MSP. It is not 894 necessary for a sender to transfer multiple MB message before the 895 receiver decides to refuse it for some reason. Connected devices may 896 efficiently synchronize their message spools even over limited 897 bandwidth connections. A short message is never blocked by a larger 898 one. 900 Should exchange of longer messages be desired, a pull model is 901 employed. A Mesh message is used to send a message advising the 902 recipient's client of the location from which the full content may be 903 obtained. This approach has many benefits over the SMTP push model. 904 There is no longer a need for any limitation on message size. The 905 same messaging platform can be used to send a short text message, a 906 spreadsheet or raw video files. 908 Exchange of certain content types naturally leads to security 909 concerns. These concerns are mitigated in the Mesh by performing 910 access control on every message. When accepting Bob as a partner, 911 Alice can choose the types of Mesh Message and the types of content 912 she is willing to accept from him. Thus, Alice might be willing to 913 accept a spreadsheet containing macro code from Bob but not from 914 Carol or Mallet. And she might not want to accept anything at all 915 from Susan because of past abuse. 917 While there are important technical differences between Mesh 918 Messaging and SMTP, these are not visible to Alice or Bob except 919 insofar as there is no restriction on message size other than the 920 storage capacity of the machine they wish to receive the messages on, 921 there is very little scope for messaging abuse and (unless the Mesh 922 becomes ubiquitous) they can only use Mesh Messaging to communicate 923 with other Mesh users. Thus, while Mesh messaging has been designed 924 to enable replacement of SMTP in the long term, it is not currently a 925 focus for the client implementations. Use of Mesh messaging is thus 926 currently limited to support for applications built on the Mesh 927 platform. One of those applications is the device connection 928 protocol describe earlier. Another is the contact exchange protocol 929 used to acquire contact information from other Mesh users. 931 4.3.1. Contact exchange 933 Besides management of private keys across devices, the biggest 934 obstacle to effective use of existing security protocols such as SSH, 935 OpenPGP and S/MIME is the difficulty of obtaining the authentic 936 public keys of the counterparties. 938 The question of issue and validation of credentials is a complex and 939 difficult one that does not have a single answer that is valid for 940 every use case. For certain applications credentials issued by a 941 Trusted Third Party are appropriate. For others, the Web of Trust 942 proposed in OpenPGP provides a better fit to the requirements and 943 constraints. These issues are discussed in 944 [draft-hallambaker-mesh-trust]. 946 Rather than imposing a single trust model for credential acquisition, 947 the Mesh allows the use of whatever model is best for validating a 948 credential for a particular use. It is unlikely Alice would have the 949 same security concerns for communication with her employer, her 950 friends, her bank, etc. 952 For many applications, Trust After First Use provides an adequate 953 basis for credential acquisition. 955 Alice wants to exchange Mesh messages with Bob. Although Alice knows 956 Bob's Mesh address (bob@example.com), she does not (yet) have 957 permission to send any message to Bob excepting a request to exchange 958 contact information. 960 Bob sends Alice a contact exchange request: 962 Bob> message contact alice@example.com 964 Alice checks his Mesh messages and approves Bob's request: 966 Alice> account sync 967 Alice> message pending 968 MessageID: NBKU-OVBZ-YZRN-FEB4-ARMW-VUVI-2JSG 969 Contact Request:: 970 MessageID: NBKU-OVBZ-YZRN-FEB4-ARMW-VUVI-2JSG 971 To: alice@example.com From: bob@example.com 972 PIN: AD6Q-2HLS-M3HL-MYNB-43SW-OXCM-QFSA 973 Alice> message accept NBKU-OVBZ-YZRN-FEB4-ARMW-VUVI-2JSG 974 ERROR - Cannot access a closed file. 976 At this point Alice and Bob can exchange Mesh messages of any type 977 with seamless end to end security. Every Mesh message is signed and 978 encrypted without exception. If Alice and Bob have used the Mesh to 979 configure their email accounts for OpenPGP or S/MIME, they can use 980 these to exchange end-to-end secure SMTP mail. 982 Alternatively, Bob might have opted to grant Alice only specific 983 messaging access. Bob might choose to restrict synchronous messaging 984 modalities such as instant messaging or voice that interrupt his 985 workflow to specific colleagues. The fact that Alice wants to speak 986 to Bob does not necessarily mean she is interested in what he might 987 say in reply. Thus, messaging access need not be reciprocated. 989 As with device connection, multiple contact exchange methods are 990 supported including the use of a QR code printed on a business card 991 or presented on a mobile device. These methods are also described in 992 [draft-hallambaker-mesh-protocol]. 994 As a respected figure within the cryptographic community, Alice might 995 employ a curation service for credential requests advising her that 996 Bob's credentials appear to be in order while Mallet's are 997 suspicious. Such services might be offered by her MSP or another 998 provider. Alice might be willing to accept contact requests from 999 members of professional associations she is a member of or who have 1000 attended certain conferences in her field. A variety of approaches 1001 might be followed for curation of other requests including Machine 1002 Learning approaches. 1004 4.3.2. Confirmation service 1006 The Mesh confirmation service is an improvement of traditional second 1007 factor authentication techniques offering offers far greater 1008 usability and security. 1010 Instead of being asked to present a meaningless numeric code, Alice 1011 is presented a request from a named, authenticated source to confirm 1012 a specific action. Alice's response will be signed using a signature 1013 key that is unique to the particular confirmation device she uses, 1014 thus providing a non-repudiable record of her decision. 1016 Alice attempts to log into a secure console in the control room. The 1017 secure console recognizes Alice but a second factor is required. The 1018 console issues a challenge to Alice at her registered account asking 1019 if she would like to log into the secure console: 1021 Console> message confirm alice@example.com start 1023 Alice checks her pending messages and accepts the request: 1025 Alice> message accept NBAC-LLBY-E4EU-7ZRF-I47O-ZYHZ-PBCW 1026 ERROR - The specified message could not be found. 1028 The secure console verifies the response and grants access: 1030 Alice> $message status {confirmResponseID} 1031 ERROR - The command System.Object[] is not known. 1033 In an enterprise environment, tying the confirmation process to a 1034 specific source, a specific action and specific device allows for 1035 confirmation interactions to be used to implement business processes 1036 with attribution and thus accountability. 1038 Using traditional second factor approaches, a system administrator 1039 presents their credentials to authenticate access to the machine at 1040 which point they can perform any action permitted by their current 1041 privileges. This typically includes modification of any access logs 1042 that might be kept. Using the confirmation approach the individual 1043 actions of the system administrator may be authenticated, traced and 1044 logged. If a user account is added to the system, it is known which 1045 administrator is responsible and the device that was used. This 1046 information may then be used if it becomes necessary to unwind the 1047 consequences of a breach or an insider threat. 1049 4.4. Encryption Groups 1051 As seen earlier, the Mesh allows encrypted files to be shared with 1052 other named users. While this capability is sufficient for simple 1053 messaging type use cases, decades of experience prove that it is 1054 inadequate to meet the needs of protecting data at rest. In the 1055 simple messaging case the list of recipients is known to the sender 1056 at the time a message is sent. In the general case the party 1057 encrypting the data cannot know the list of intended readers because 1058 that will change over time. 1060 Even in the smallest organization, employees join and leave. A new 1061 employee must be granted access to all the information they need for 1062 their work. The access rights of a terminated employee must also 1063 terminate. 1065 Traditional 'Digital Rights Management' product employ key management 1066 techniques originating in the field of copyright enforcement to 1067 control access to content by controlling disclosure of symmetric 1068 decryption keys. This provides the necessary flexibility to control 1069 access to the data but leaves the decryption keys vulnerable to a 1070 server breach. Such systems do not provide 'end-to-end' security in 1071 any useful sense. 1073 Use of threshold techniques allows a threshold service to control 1074 decryption of the data without having the ability to decrypt. 1075 Sharing data through a Mesh group allows access to be controlled 1076 without loss of end-to-end encryption. 1078 Alice creates the recryption group groupw@example.com to share 1079 confidential information with her closest friends: 1081 Alice> group create groupw@example.com 1082 ERROR - Cannot access a closed file. 1084 Bob encrypts a test file but he can't decrypt it because he isn't in 1085 the group: 1087 Alice> dare encode grouptext.txt /encrypt groupw@example.com /out ^ 1088 groupsecret.dare 1089 ERROR - The option System.Object[] is not known. 1091 Even though she is the group administrator, Alice can't decrypt the 1092 file either until she adds herself to the group. 1094 Alice> dare decode groupsecret.dare 1095 ERROR - No decryption key is available 1096 Alice adds Bob to the group: 1098 Missing example 2 1100 Adding Bob to the group gives him immediate access to any file 1101 encrypted under the group key without making any change to the 1102 encrypted files: 1104 Missing example 3 1106 Removing Bob from the group immediately withdraws his access. 1108 Missing example 4 1110 Bob cannot decrypt any more files (but he may have kept copies of 1111 files he decrypted earlier). 1113 Missing example 5 1115 4.5. Escrow and Recovery 1117 While disclosure of sensitive data might cause serious harm to its 1118 owner it is very rarely the case that the consequences of disclosure 1119 are greater than the consequences of loss. Thus, whenever static 1120 data is to be encrypted, the question of key recovery must be 1121 considered. 1123 Alice decides to create a recovery key set. To do this, she 1124 specifies the number of key shares to be created and the number 1125 required for recovery: 1127 Alice> account escrow 1128 Share: SAQN-H7KA-DN7Z-SWGM-NTOL-EBGN-TGJN-UNEA-H4LH-VTYK-P66S-KE3D-JI 1129 FE-NWOY-JRGQ 1130 Share: SAQ5-76L5-SN7F-BMIK-AQRW-DU7F-FDJY-P3C6-DQZE-LOLJ-IGRQ-O2IY-6E 1131 G2-UQ3Z-BCUQ 1132 Share: SARO-X5N3-BN6Q-QCKH-TNVB-DIX4-XAKD-LJB3-7FHB-BI6I-AOEO-TPWO-TA 1133 IQ-3LIZ-YUCQ 1135 Recovery of the key data requires the key recovery record and a 1136 quorum of the key shares: 1138 Alice2> account recover /verify 1139 ERROR - Expected { 1141 4.6. Future Applications 1143 The Mesh is a Threshold Key Infrastructure and as with any 1144 infrastructure, it is designed as a platform to support as wide a 1145 range of future developments as possible. As shown previously, the 1146 Mesh Messaging system provides an improved superset of the functions 1147 of SMTP. It is also capable of being extended to support every 1148 current communication modality with true end-to-end protection of 1149 data confidentiality. 1151 4.6.1. Synchronous Messaging 1153 Addition of a presence service capability to the MSP would allow Mesh 1154 Messaging to be used to support the full range of synchronous 1155 messaging services from text chat (e.g. xmpp) to video and VOIP. 1157 The main technical issue to be addressed to enable such a service is 1158 specifying a means of layering Mesh Messages direct over UDP 1159 transport. This is currently at the concept phase. While the 1160 precise means of layering audio and video formats onto a network 1161 connection is a complex problem, it is one that has already been 1162 solved by existing standards. 1164 4.6.2. Social Media 1166 One of the chief distinctions between messaging and 'social media' 1167 and is that the former is typically used to describe a synchronous 1168 interaction between a closed group of users while most social media 1169 consists of asynchronous interactions which are frequently (but not 1170 always) public. 1172 The Data At Rest Envelope technology used in the Mesh was originally 1173 designed to support asynchronous social media interactions with full 1174 end-to-end confidentiality. The service hosting a forum or 1175 discussion board need not have access to the content of the messages 1176 to support the complete range of user interactions. 1178 5. Mesh Cryptography 1180 All the cryptographic algorithms used in the Mesh are either industry 1181 standards or present a work factor that is provably equivalent to an 1182 industry standard approach. Since threshold cryptography is not 1183 currently part of the 'canon' from which designers of cryptographic 1184 security protocols work, much of the cryptography used in the Mesh 1185 has been designed for the Mesh. Despite this fact, it is properly 1186 regarded as part of the Internet platform on which the Mesh is built 1187 rather than a part of the Mesh itself. 1189 Existing Internet security protocols are based on approaches 1190 developed in the 1990s when performance tradeoffs were a prime 1191 consideration in the design of cryptographic protocols. Security was 1192 focused on the transport layer as it provided the best security 1193 possible given the available resources. 1195 With rare exceptions, most computing devices manufactured in the past 1196 ten years offer either considerably more computing power than was 1197 typical of 1990s era Internet connected machines or considerably 1198 less. The Mesh architecture is designed to provide security 1199 infrastructure both classes of machine but with the important 1200 constraint that the less capable 'constrained' devices are considered 1201 to be 'network capable' rather than 'Internet capable' and that the 1202 majority of Mesh related processing will be offloaded to another 1203 device. 1205 For example, Alice uses her Desktop and Laptop to exchange end-to-end 1206 secure Mesh Messages and documents but her Internet-of-Things food 1207 blender and light bulb are limited in the range of functions they 1208 support and the telemetry information they provide. The IoT devices 1209 connect to a Mesh Hub which acts as an always-on point of presence 1210 for the device state and allows complex cryptographic operations to 1211 be offloaded if necessary. 1213 (Artwork only available as svg: No external link available, see 1214 draft-hallambaker-mesh-architecture-15.html for artwork.) 1216 Figure 2 1218 5.1. Best Practice by Default 1220 Except where support for external applications demand otherwise, the 1221 Mesh requires that the following 'best practices' be followed: 1223 Industry Standard Algorithms All cryptographic protocols make use of 1224 the most recently adopted industry standard algorithms. 1226 Strongest Work Factor Only the strongest modes of each cipher 1227 algorithm are used. All symmetric encryption is performed with 1228 256-bit session keys and all digest algorithms are used in 512-bit 1229 output length mode. 1231 Key Hygiene Separate public key pairs are used for all cryptographic 1232 functions: Encryption, Signature and Authentication. This enables 1233 separate control regimes for the separate functions and 1234 partitioning of cryptographic functions within the application 1235 itself. 1237 Bound Device Keys Each device has a separate set of Encryption, 1238 Signature and Authentication key pairs. These MAY be bound to the 1239 device to which they are assigned using hardware or other 1240 techniques to prevent or discourage export. 1242 No Optional Extras Traditional approaches to security have treated 1243 many functions as being 'advanced' and thus suited for use by only 1244 the most sophisticated users. The Mesh rejects this approach 1245 noting that all users operate in precisely the same environment 1246 facing precisely the same threats. 1248 5.2. Multi-Level Security 1250 All Mesh protocol transactions are protected at the Transport, 1251 Message and Data level. This provides security in depth that cannot 1252 be achieved by applying security at the separate levels 1253 independently. Data level encryption provides end-to-end 1254 confidentiality and non-repudiation, Message level authentication 1255 provides the basis for access control and Transport level encryption 1256 provides a degree of protection against traffic analysis. 1258 5.3. Threshold Decryption 1260 Traditional public key encryption algorithms have two keys, one for 1261 encryption and another for decryption. The Mesh makes use of 1262 threshold cryptography techniques to allow the decryption key to be 1263 split into two or more parts. 1265 For example, if we have a private key _z_, we can use this to perform 1266 a key agreement with a public key _S_ to obtain the key agreement 1267 value A. But if _z_ = (_x+y_) mod _g_ (where g is the order of the 1268 group). we can obtain the exact same result by applying the private 1269 keys _x_ and _y_ to _S_ separately and combining the results: 1271 (Artwork only available as svg: No external link available, see 1272 draft-hallambaker-mesh-architecture-15.html for artwork.) 1274 Figure 3 1276 The approach to threshold decryption used in the Mesh was originally 1277 inspired by the work of Matt Blaze et. al. on proxy re-encryption. 1278 But the approach used may also be considered a form of Torben 1279 Pedersen's Distributed Key generation which is in turn one form of 1280 threshold cryptography. 1282 This technique is used in the Mesh to allow use of decryption key 1283 held by a user to be controlled by a cloud service without giving the 1284 cloud service the ability to decrypt by itself. 1286 These techniques are described in detail in 1287 [draft-hallambaker-threshold]. 1289 5.4. Threshold Key Generation 1291 The mathematics that support threshold decryption are also the basis 1292 for the multi-party key generation mechanism that is applied at 1293 multiple levels in the Mesh. The basis for the multi-party key 1294 generation used in the Mesh is that for any Diffie-Hellman type 1295 cryptographic scheme, given two keypairs { _x_, _X_ }, { _y_, _Y_ }, 1296 we calculate the public key corresponding to the private key _x_+ _y_ 1297 using just the public key values _X_and _Y_. 1299 (Artwork only available as svg: No external link available, see 1300 draft-hallambaker-mesh-architecture-15.html for artwork.) 1302 Figure 4 1304 Threshold key generation ensures that keys used to bind devices to a 1305 personal Mesh or within a Mesh account are 'safe' if any of the 1306 contributions to the generation process are safe. 1308 These techniques are also described in detail in 1309 [draft-hallambaker-threshold]. 1311 5.5. Threshold Signature 1313 The techniques that support threshold decryption and key generation 1314 are also applicable to signature albeit with some very important 1315 constraints. Incorrect implementation of the techniques used to 1316 create ECDSA signatures can result in disclosure of the private key. 1317 It is therefore essential that a threshold signature algorithm is 1318 rigorously reviewed. 1320 This technique is used in the mesh to partition the use of 1321 administration keys so that the consequences of losing an 1322 administrative device can be mitigated. 1324 These techniques are described in detail in 1325 [draft-hallambaker-threshold-sigs]. 1327 5.6. Data At Rest Encryption 1329 The Data At Rest Encryption (DARE) format is used for all 1330 confidentiality and integrity enhancements. The DARE format is based 1331 on the JOSE Signature and Encryption formats and the use of an 1332 extended version of the JSON encoding allowing direct encoding of 1333 binary objects. 1335 5.6.1. DARE Envelope 1337 The DARE Envelope format offers similar capabilities to existing 1338 formats such as OpenPGP and CMS without the need for onerous encoding 1339 schemes. DARE Assertions are presented as DARE Envelopes. 1341 A feature of the DARE Envelope format not supported in existing 1342 schemes is the ability to encrypt and authenticate sets of data 1343 attributes separately from the payload. This allows features such as 1344 the ability to encrypt a subject line or content type for a message 1345 separately from the payload. 1347 5.6.2. Dare Container 1349 A DARE Container is an append-only sequence of DARE Envelopes. A key 1350 feature of the DARE Container format is that entries MAY be encrypted 1351 and/or authenticated incrementally. Individual entries MAY be 1352 extracted from a DARE Container to create a stand-alone DARE 1353 Envelope. 1355 Containers may be authenticated by means of a Merkle tree of digest 1356 values on the individual frames. This allows similar demonstrations 1357 of integrity to those afforded by Blockchain to be provided but with 1358 much greater efficiency. 1360 Unlike traditional encryption formats which require a new public key 1361 exchange for each encrypted payload, the DARE Container format allows 1362 multiple entries to be encrypted under a single key exchange 1363 operation. This is particularly useful in applications such as 1364 encrypting server transaction logs. The server need only perform a 1365 single key exchange operation each time it starts to establish a new 1366 shared secret for that session. The shared secret is then used to 1367 create fresh symmetric keying material for each entry in the log 1368 using a unique nonce per entry. 1370 (Artwork only available as svg: No external link available, see 1371 draft-hallambaker-mesh-architecture-15.html for artwork.) 1373 Figure 5 1375 Integrity is provided by a Merkle tree calculated over the sequence 1376 of log entries. The tree apex is signed at regular intervals to 1377 provide non-repudiation. 1379 Three types of DARE Containers are used in the mesh 1381 Catalogs A DARE Container whose entries track the status of a set of 1382 related objects which may be added, updated, or deleted. 1384 Spools A DARE Container whose entries track the status of a series 1385 of Mesh Messages. 1387 Archives A DARE Container used to provide a file archive with 1388 optional confidentiality and/or integrity enhancements. 1390 5.7. Uniform Data Fingerprints. 1392 The Uniform Data Fingerprint (UDF) format provides a compact means of 1393 presenting cryptographic nonces, keys and digest values using Base32 1394 encoding that resists semantic substitution attacks. UDF provides a 1395 convenient format for data entry. Since the encoding used is case- 1396 insensitive, UDFs may if necessary be read out over a voice link 1397 without excessive inconvenience. 1399 The following are examples of UDF values: 1401 NAB6-GXIR-GXA5-AQJO-4CNH-LWOL-EOVQ 1402 7UHC-4YPF-LDY4-2F65-7DYN-UUPC-ZY 1403 SAQF-HCGQ-JTQ5-5YGF-PT4S-QPXL-KOPE-U 1404 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 1405 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 1406 AABD-4PN3-QGA2-IJU5-RP7H-Z5AV-I3GK 1408 UDF content digests are used to support a direct trust model similar 1409 to that of OpenPGP. Every Mesh Profile is authenticated by the UDF 1410 fingerprint of its signature key. Mesh Friendly Names and UDF 1411 Fingerprints thus serve analogous functions to DNS names and IP 1412 Addresses. Like DNS names, Friendly Names provide the basis for 1413 application-layer interactions while the UDF Fingerprints are used as 1414 to provide the foundation for security. 1416 5.7.1. Friendly Names 1418 Internet addressing schemes are designed to provide a globally unique 1419 (or at minimum unambiguous) name for a host, service or account. In 1420 the early days of the Internet, this resulted in addresses such as 1421 10.2.3.4 and alice@example.com which from a usability point of view 1422 might be considered serviceable if not ideal. Today the Internet is 1423 a global infrastructure servicing billions of users and tens of 1424 billions of devices and accounts are more likely to be 1425 alice.lastname.1934@example.com than something memorable. 1427 Friendly names provide a user or community specific means of 1428 identifying resources that may take advantage of geographic location 1429 or other cues to resolve possible ambiguity. If Alice says to her 1430 voice activated device "close the garage door" it is implicit that it 1431 is her garage door that she wishes to close. And should Alice be 1432 fortunate enough to own two houses with a garage, it is implicit that 1433 it is the garage door of the house she is presently using that she 1434 wishes to close. 1436 The Mesh Device Catalog provides a directory mapping friendly names 1437 to devices that is available to all Alice's connected devices so that 1438 she may give and instruction to any of her devices using the same 1439 friendly name and expect consistent results. 1441 5.7.2. Encrypted Authenticated Resource Locators 1443 Various schemes have been used to employ QR Codes as a means of 1444 device and/or user authentication. In many of these schemes a QR 1445 code contains a challenge nonce that is used to authenticate the 1446 connection request. 1448 The Mesh supports a QR code connection mode employing the Encrypted 1449 Authenticated Resource Locator (EARL) format. An EARL is an 1450 identifier which allows an encrypted data object to be retrieved and 1451 decrypted. In this case, the encrypted data object contains the 1452 information needed to complete the interaction. 1454 An EARL contains the domain name of the service providing the 1455 resolution service and an encryption master key: 1457 mcu://alice@example.com/ADJ5-4NLV-O7YC-SKR6-EI 1459 The EARL may be expressed as a QR code: 1461 (Artwork only available as svg: No external link available, see 1462 draft-hallambaker-mesh-architecture-15.html for artwork.) 1464 Figure 6 1466 An EARL is resolved by presenting the content digest fingerprint of 1467 the encryption key to a Web service hosted at the specified domain. 1468 The service returns a DARE Envelope whose payload is encrypted and 1469 authenticated under the specified master key. Since the content is 1470 stored on the service under the fingerprint of the key and not the 1471 key itself, the service cannot decrypt the plaintext. Only a party 1472 that has access to the encryption key in the QR code can decrypt the 1473 message. 1475 5.7.3. Secure Internet Names 1477 Secure Internet Names bind an Internet address such as a URL or an 1478 email address to a Security Policy by means of a UDF content digest 1479 of a document describing the security policy. This binding enables a 1480 SIN-aware Internet client to ensure that the security policy is 1481 applied when connecting to the address. For example, ensuring that 1482 an email sent to an address must be end-to-end encrypted under a 1483 particular public key or that access to a Web Service requires a 1484 particular set of security enhancements. 1486 alice@example.com Alice's regular email address (not a SIN). 1488 alice@mm--uuuu-uuuu-uuuu.example.com A strong email address for 1489 Alice that can be used by a regular email client. 1491 alice@example.com.mm--uuuu-uuuu-uuuu A strong email address for 1492 Alice that can only used by an email client that can process SINs. 1494 Using an email address that has the Security Policy element as a 1495 prefix allows a DNS wildcard element to be defined that allows the 1496 address to be used with any email client. Presenting the Security 1497 Policy element as a suffix means it can only be resolved by a SIN- 1498 aware client. 1500 5.8. Personal Key Escrow 1502 One of the core objectives of the Mesh is to make data level 1503 encryption ubiquitous. While data level encryption provides robust 1504 protection of data confidentiality, loss of the ability to decrypt 1505 means data loss. 1507 For many Internet users, data availability is a considerably greater 1508 concern than confidentiality. Ten years later, there is no way to 1509 replace pictures of the children at five years old. Recognizing the 1510 need to guarantee data recovery, the Mesh provides a robust personal 1511 key escrow and recovery mechanism. Lawful access is not supported as 1512 a requirement. 1514 Besides supporting key recovery in the case of loss, the Mesh 1515 protocols potentially support key recovery in the case of the key 1516 holder's death. The chief difficulty faced in implementing such a 1517 scheme being developing an acceptable user interface which allows the 1518 user to specify which of their data should survive them and which 1519 should not. As the apothegm goes: Mallet wants his beneficiaries to 1520 know where he buried Aunt Agatha's jewels but not where he buried 1521 Aunt Agatha. 1523 The Mesh supports use of Shamir/Lagrange secret sharing and recovery 1524 to split a secret key into a set of shares, a predetermined number of 1525 which may be used to recover the original secret. For convenience 1526 secret shares are represented using UDF allowing presentation in 1527 Base32 (i.e. text format) for easy transcription or QR code 1528 presentation if preferred. 1530 To facilitate escrow and recovery, all the public key pairs and key 1531 shares associated with a Mesh profile are generated from a seed value 1532 using a deterministic algorithm. Thus, escrow of the seed value is 1533 sufficient to permit recovery of the private key data. 1535 For example, Alice escrows her Mesh Profile creating three recovery 1536 shares, two of which are required to recover the master secret: 1538 (Artwork only available as svg: No external link available, see 1539 draft-hallambaker-mesh-architecture-15.html for artwork.) 1541 Figure 7 1543 To recover the master secret, Alice presents the necessary number of 1544 key shares. These are used to recover the master secret which is 1545 used to generate the decryption key: 1547 (Artwork only available as svg: No external link available, see 1548 draft-hallambaker-mesh-architecture-15.html for artwork.) 1550 Figure 8 1552 A user may choose to store their encrypted recovery record themselves 1553 or make use of the EARL mechanism to store the information at one or 1554 more cloud services using the fingerprint of the master secret as the 1555 locator. 1557 6. Mesh Architecture 1559 The Mesh infrastructure is supported by a compact set of structures 1560 and protocols. These are discussed in detail in the Schema Reference 1561 [draft-hallambaker-mesh-schema] and Protocol Reference 1562 [draft-hallambaker-mesh-protocol] documents. 1564 The JSON object model and JSON or JSON-B serialization 1565 [draft-hallambaker-jsonbcd] are used for all Mesh data structures. 1566 These include: 1568 Assertions A DARE envelope containing a signed data object. 1569 Assertions include Profiles and Connections. 1571 Profile A self-signed assertion describing a Mesh principal. 1572 Principals include Accounts, Devices and Services. 1574 Every profile specifies a profile signature key under which it is 1575 signed. The UDF fingerprint of the profile signature key is used 1576 as a unique identifier for the profile. Thus, all attributes 1577 declared in the profile such as authentication keys and encryption 1578 keys are bound to the unique identifier for the profile. 1580 Connection An assertion signed by one principal delegating rights to 1581 another. Connection assertions are used to bind devices to 1582 accounts and hosts to a service. 1584 Activation A DARE envelope encrypted under the encryption key of a 1585 principal that grant rights or capabilities to that principal. 1586 This is typically but not always achieved through use of threshold 1587 key techniques. 1589 Message A DARE envelope signed by the sender that is encrypted under 1590 the encryption key of the intended recipient(s) whose content is a 1591 Mesh messaging object. 1593 Entry An object stored in a catalog that carries an identifier that 1594 is unique for that catalog. 1596 6.1. Actors 1598 Three Mesh actors are defined: Accounts, Devices and Services. Each 1599 of these is described by a specific type of profile. 1601 6.1.1. Account 1603 Two types of Mesh account are currently specified: personal accounts 1604 and group accounts. For concise exposition, this document is limited 1605 to the description of personal accounts. Group accounts are 1606 specified in the Schema Reference [draft-hallambaker-mesh-schema]. 1608 A Mesh account is an abstraction which may be loosely regarded as the 1609 thing to which a collection of devices (in the case of a user 1610 account) or a collection of members (in the case of a group account) 1611 belong. 1613 Each personal account profile specifies: 1615 Profile Signature Key Used to authenticate the profile. Updates to 1616 the profile require use of the Profile Signature Key. The Profile 1617 Signature Key cannot be changed but a profile may be replaced by a 1618 new profile. 1620 Uniform Data Fingerprint The UDF fingerprint of the Profile 1621 Signature Key. This is used as a unique identifier for the 1622 account. 1624 Account Name The account name through which the profile is serviced. 1626 Administration Keys UDF fingerprint of keys that are authorized to 1627 sign device connection assertions and update the Device Catalog. 1629 Signature Key Public parameters of the account signature key. This 1630 is the key that counterparties will use to verify messages sent by 1631 the account holder. 1633 Encryption Key Public parameters of the account encryption key. 1634 This is the key that counterparties will use to encrypt messages 1635 sent to the account holder. 1637 Authentication Key Public parameters of the account authentication 1638 key. This is the key that counterparties will use to establish 1639 authenticated exchanges with the account holder. 1641 The public keys for encryption, authentication and signature 1642 specified in the account profile are the only keys that will (in 1643 normal circumstances) be visible to other Mesh accounts. 1645 6.1.2. Device 1647 A Mesh Device is any device that is connected to a Mesh Account 1648 through a Device profile. A given physical device may have multiple 1649 device profiles associated with it but for the purposes of the Mesh, 1650 these are considered to be separate devices. A given device profile 1651 may be connected to more than one account 1653 The device profile specifies: 1655 Profile Signature Key Used to authenticate the profile. Updates to 1656 the profile require use of the Profile Signature Key. The Profile 1657 Signature Key cannot be changed but a profile may be replaced by a 1658 new profile. 1660 Uniform Data Fingerprint The UDF fingerprint of the Profile 1661 Signature Key. This is used as a unique identifier for the device. 1663 Signature Key Public parameters of the device signature key share. 1664 This key share is used as a contribution to the signature key the 1665 device will use in the context of the account and to authenticate 1666 device connection requests. 1668 Encryption Key Public parameters of the account encryption key 1669 share. This key share is used as a contribution to the encryption 1670 key the device will use in the context of the account and to 1671 decrypt activation records sent in response to device connection 1672 requests. 1674 Authentication Key Public parameters of the account authentication 1675 key share. This key share is used as a contribution to the 1676 authentication key the device will use in the context of the 1677 account. 1679 Description Optional information describing the device provided by 1680 the manufacturer. E.g. model, serial number, date of manufacture 1681 etc. 1683 A Mesh Device is connected to an account through the creation of an 1684 activation record and a connection record. 1686 The activation record contains key shares that are overlaid on the 1687 corresponding shares specified in the device profile to create the 1688 set of encryption, authentication and signature keys the device will 1689 use in the context of the account. Since the private keys 1690 corresponding to the device profile keys are only used to enable the 1691 connection of the device to an account, these keys are only trusted 1692 to a minimal degree. 1694 (Artwork only available as svg: No external link available, see 1695 draft-hallambaker-mesh-architecture-15.html for artwork.) 1697 Figure 9 1699 In the ideal case, the device profile keys are fixed to the device 1700 such that they may be used to perform private key operations without 1701 the ability to extract the private key data from the device. Since 1702 the device profile is only trusted for the limited purpose of 1703 connecting the device to an account, the device profile may be 1704 created during manufacture without undue concern for either 1705 disclosure of the private key on the part of the account holder or a 1706 reputation attack alleging disclosure of the private key on the part 1707 of the manufacturer. 1709 The device connection record is functionally a certificate that the 1710 device may use to interact with the Mesh Service or to other devices 1711 connected to the same account. Note however that use of threshold 1712 cryptography means that Mesh devices would not normally present their 1713 device connection record to any other party since all communication 1714 with external parties takes place through the keys published in the 1715 account profile. 1717 6.1.3. Service 1719 A Mesh Service is an abstract network service that is provided by one 1720 or more hosts. The properties of the service are described by the 1721 service profile. 1723 The service profile specifies: 1725 Profile Signature Key Used to authenticate the profile. Updates to 1726 the profile require use of the Profile Signature Key. The Profile 1727 Signature Key cannot be changed but a profile may be replaced by a 1728 new profile. 1730 Uniform Data Fingerprint The UDF fingerprint of the Profile 1731 Signature Key. This is used as a unique identifier for the device. 1733 Signature Key Public parameters of the service signature key. This 1734 is the key that counterparties will use to verify messages sent by 1735 the service. 1737 Encryption Key Public parameters of the service encryption key. 1738 This is the key that counterparties will use to encrypt messages 1739 sent to the service. 1741 Authentication Key Public parameters of the account authentication 1742 key. This is the key that counterparties will use to establish 1743 authenticated exchanges with the service. 1745 Hosts are Mesh Devices that have been granted a Host Activation and 1746 Host Connection by a service administrator. These are used in the 1747 same fashion as the device activation and connection records. 1749 6.2. Stores 1751 Mesh Stores are append-only sequences that are used to represent 1752 collections of objects, messages and data. All Mesh stores are 1753 implemented as DARE Sequences authenticated by means of a Merkle 1754 tree. The payload of each envelope in the sequence is usually 1755 encrypted. 1757 Three types of Mesh store are currently defined: 1759 Catalog A set of Mesh objects, each of which has an identifier that 1760 is unique in the scope of the catalog. Objects may be added, 1761 updated, and deleted. 1763 Spool A sequence of Mesh Messages. 1765 All the state represented within a Mesh account is contained in Mesh 1766 stores bound to the account. Thus, to synchronize a device to the 1767 state of the account, it is sufficient to synchronize the collection 1768 of stores the device is permitted to read. Since every store is an 1769 append-only sequence, it is sufficient for the Mesh service to return 1770 the envelopes added to each of the stores since the device was last 1771 synchronized. 1773 Rapid synchronization of catalogs and spools is ensured by limiting 1774 the size of entries to each. Implementations may further improve 1775 performance by redacting stores to remove obsolete entries that have 1776 been updated or deleted. Alternatively, a device may maintain a 1777 complete record of the state of the store to allow erroneous changes 1778 to the store to be unwound. 1780 6.2.1. Catalogs 1782 Mesh Catalogs track a collection of entries. Every Mesh account 1783 contains a Threshold Catalog that is used by Mesh services as the 1784 source of access control policy. The Threshold Catalog is unique in 1785 that it is the only catalog whose contents can be read by the Mesh 1786 Service. Every other Mesh Catalog connected to a Mesh account is 1787 end-to-end encrypted so that it can only be read by devices connected 1788 to the account. 1790 The Mesh specifies various catalogs that are used to track 1791 information relevant to a Mesh Account: 1793 Device The devices connected to the corresponding Mesh profile. 1795 Contact Logical and physical contact information for people and 1796 organizations. 1798 Bookmark Web bookmarks and citations. 1800 Credential Username and password information for network resources. 1802 Calendar Appointments and tasks. 1804 Network Network access configuration information allowing access to 1805 wireless networks and VPNs. 1807 Application Configuration information for applications including 1808 mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH. 1810 Each catalog connected to an account has a unique identifier of the 1811 form "mmm_<". Applications may specify additional catalogs 1812 without risk of collision with future Mesh catalogs by using an 1813 appropriate IANA assigned protocol label. 1815 6.2.2. Spools 1817 Spools are used to track inbound and outbound messages. Three spools 1818 are currently defined: 1820 Inbound Messages that have been received by the service and accepted 1821 for delivery to the account. 1823 Outbound Messages that have been sent from the account through the 1824 service. 1826 Local A spool used to exchange messages with devices connecting to 1827 the device. 1829 6.3. Mesh Service Protocol 1831 Mesh services communicate with Mesh devices and other Mesh Services 1832 through the Mesh Service Protocol. Despite the wide range of Mesh 1833 functionality, the Mesh protocol is remarkably compact. The bulk of 1834 the semantics associated with the Mesh are expressed in the schemas 1835 describing Mesh Messages and Catalogs. The objective of reducing the 1836 degree of trust in the Mesh service to the absolute minimum by 1837 necessity requires that the Mesh Service be extremely simple. 1839 Mesh Service Protocol transactions are divided into the following 1840 groups: 1842 Service Description The Hello transaction returns a description of 1843 the service including information used to authenticate future 1844 interactions with the service. 1846 Account Management The "Create" and "Delete" transactions are used 1847 to bind an account to a service. 1849 Device Connection The "Connect" and "Complete" transactions are used 1850 to connect devices to an account 1852 Synchronization The "Status", "Download" and "Transact" transactions 1853 are used to update stores connected to an account. 1855 Messaging The "Post" transaction is used by one Mesh Service to 1856 transfer a message from one of its users to a different Mesh 1857 Service serving one of the recipients. 1859 Publication The "Publish", "Claim" and "PollClaim" transactions are 1860 used to publish and retrieve data objects through an account. 1862 Cryptographic The "Operate" transaction requests that the service 1863 performs a cryptographic operation on behalf of the account. This 1864 is used to provide execution of threshold operations on behalf of 1865 the account holder for both internal and external users. 1867 Future versions of the Mesh Service Protocol may support additional 1868 transactions to support features such as providing DNS resolution. 1870 6.3.1. Protocol Interactions 1872 Every Mesh Service Protocol transaction consists of a single request 1873 from a Mesh client followed by a single response. Requests and 1874 responses are authenticated and encrypted under a key established 1875 between the client and the service. This application layer 1876 enhancement is in addition to any transport layer enhancement that 1877 may be employed (e.g. TLS). 1879 Mesh Service Protocol messages may be exchanged through any binding 1880 advertised by the service by means of the Hello transaction. 1881 Currently only one binding is defined, mapping Mesh requests and 1882 responses to the content data of HTTP POST requests and responses 1883 layers over a TLS transport. 1885 While the use of up to three layers of encryption may be regarded as 1886 excessive, each layer provides separate protections: 1888 Transport Layer Provides confidentiality for metadata and limited 1889 traffic analysis protections. 1891 Application Layer Encryption and authentication of requests and 1892 responses using keys bound to the specific device and service 1893 performing the interaction provides the basis for access control. 1895 Data Layer Encryption of stored data (catalog data, device 1896 activations, etc.) provides end to end security between the 1897 devices connected to the account. 1899 6.4. The Threshold Catalog 1901 The Threshold Catalog of a Mesh account provides the basis through 1902 which the service implements the access control policy specified by 1903 the account. 1905 Each entry in the catalog specifies an operation that the service 1906 will perform when it receives a request that is authenticated and 1907 authorized by the access control policy specified in the entry. 1908 Operations include: 1910 Inbound Message Filtering Messages received by the service that 1911 match the specified criteria will be appended to the inbound 1912 message spool. 1914 Threshold Key Generation Performs a threshold key splitting 1915 operation of a private key held by the service and encrypts one 1916 part under a key known only to the service and encrypts the other 1917 under a public key specified by the party making the request. 1919 Key Agreement Performs a key agreement operation on a private key 1920 held by the service. This may be used as a component in a 1921 threshold key agreement scheme. 1923 Signature Performs a signature operation on a private key held by 1924 the service. This may be used as a component in a threshold 1925 signature scheme. 1927 These operations provide the vocabulary from which a Threshold Key 1928 Infrastructure is built. Keys that are bound to a service using 1929 threshold techniques can only be applied with the co-operation of 1930 that service. 1932 6.5. Mesh Messaging Protocol 1934 Mesh devices connected to an account interact with the Mesh Service 1935 through the Mesh Service protocol. Mesh devices interact with other 1936 Mesh devices through the Mesh Messaging Protocols, each of which 1937 provides a distinct application functionality: 1939 * Connection Protocol 1941 * Confirmation Protocol 1943 * Contact Exchange Protocol 1945 Each of these protocols is described in depth in the Mesh Protocol 1946 Reference [draft-hallambaker-mesh-protocol]. 1948 Mesh Messages provide a means of communication between Mesh Service 1949 Accounts with capabilities that are not possible or poorly supported 1950 in traditional SMTP mail messaging: 1952 * End-to-end confidentiality and authentication by default. 1954 * Abuse mitigation by applying access control to every inbound and 1955 outbound message. 1957 * End-to-end secure group messaging. 1959 * Transfer of exceptionally large data sets (Terabytes). 1961 Note that although Mesh Messaging is designed to facilitate the 1962 transfer of very large data sets, the size of Mesh Messages 1963 themselves is severely restricted. The current default maximum size 1964 being 64 KB. This approach allows Mesh 1966 In addition, the platform anticipates but does not currently support 1967 additional cryptographic security capabilities: 1969 * Traffic analysis resistance using mix networks (Chaum). 1971 * Simultaneous contract binding using fair contract signing 1972 (Micali). 1974 While these capabilities might in time cause Mesh Messaging to 1975 replace SMTP, this is not a near term goal. The short-term goal of 1976 Mesh Messaging is to support the Contact Exchange and Confirmation 1977 applications. 1979 Two important classes of application that are not currently supported 1980 directly are payments and presence. While prototypes of these 1981 applications have been considered, it is not clear if these are best 1982 implemented as special cases of the Confirmation and Contact Exchange 1983 applications or as separate applications in their own right. 1985 Messages exchanged between Mesh Users MUST be mediated by a Mesh 1986 Service for both sending and receipt. This 'four corner' pattern 1987 permits ingress and egress controls to be enforced on the messages 1988 and that every message is properly recorded in the appropriate 1989 spools. 1991 (Artwork only available as svg: No external link available, see 1992 draft-hallambaker-mesh-architecture-15.html for artwork.) 1994 Figure 10 1996 For example, to send a message to Alice, Bob posts it to one of the 1997 Mesh Services connected to the Mesh Account from which the message is 1998 to be sent. The Mesh Service checks to see that both the message and 1999 Bob's pattern of behavior comply with their acceptable use policy and 2000 if satisfactory, forwards the message to the receiving service 2001 example.com. 2003 (Artwork only available as svg: No external link available, see 2004 draft-hallambaker-mesh-architecture-15.html for artwork.) 2006 Figure 11 2008 The receiving service uses the recipient's contact catalog and other 2009 information to determine if the message should be accepted. If 2010 accepted, the message is added to the recipient's inbound message 2011 spool to be collected by her device(s) when needed. 2013 (Artwork only available as svg: No external link available, see 2014 draft-hallambaker-mesh-architecture-15.html for artwork.) 2016 Figure 12 2018 For efficiency and to limit the scope for abuse, all inbound Mesh 2019 Messages are subject to access control and limited in size to 32KB or 2020 less. This limit has proved adequate to support transfer of complex 2021 control messages and short content messages. Transfer of data 2022 objects of arbitrary size may be achieved by sending a control 2023 message containing a URI for the main content which may then be 2024 fetched using a protocol such as HTTP. 2026 This approach makes transfers of exceptionally large data sets (i.e. 2027 multiple Terabytes) practical as the 'push' phase of the protocol is 2028 limited to the transfer of the initial control message. The bulk 2029 transfer is implemented as a 'pull' protocol allowing support for 2030 features such as continuous integrity checking and resumption of an 2031 interrupted transfer. 2033 6.6. Using the Mesh with Applications 2035 The Mesh provides an infrastructure for supporting existing Internet 2036 security applications and a set security features that may be used to 2037 build new ones. 2039 For example, Alice uses the Mesh to provision and maintain the keys 2040 she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the 2041 credential catalog for end-to-end secure management of the usernames 2042 and passwords for her Web browsing and other purposes: 2044 (Artwork only available as svg: No external link available, see 2045 draft-hallambaker-mesh-architecture-15.html for artwork.) 2047 Figure 13 2049 The Mesh design is highly modular allowing components that were 2050 originally designed to support a specific requirement within the Mesh 2051 to be applied generally. 2053 6.6.1. Future Applications 2055 Since a wide range of network applications may be reduced to 2056 synchronization of sets and lists, the basic primitives of Catalogs 2057 and Spools may be applied to achieve end-to-end security in an even 2058 wider variety of applications. 2060 For example, a Spool may be used to maintain a mailing list, track 2061 comments on a Web forum or record annotations on a document. 2062 Encrypting the container entries under a multi-party encryption group 2063 allows such communications to be shared with a group of users while 2064 maintaining full end-to-end security and without requiring every 2065 party writing to the spool to know the public encryption key of every 2066 recipient. 2068 Another interesting possibility is the use of DARE Containers as a 2069 file archive mechanism. A single signature on the final Merkle Tree 2070 digest value would be sufficient to authenticate every file in the 2071 archive. Updates to the archive might be performed using the same 2072 container synchronization primitives provided by a Mesh Service. 2073 This approach could afford a robust, secure, and efficient mechanism 2074 for software distribution and update. 2076 7. Security Considerations 2078 The security considerations for use and implementation of Mesh 2079 services and applications are described in the Mesh Security 2080 Considerations guide [draft-hallambaker-mesh-security]. 2082 8. IANA Considerations 2084 This document does not contain actions for IANA 2086 9. Acknowledgements 2088 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 2089 Alden. 2091 10. Normative References 2093 [draft-hallambaker-jsonbcd] 2094 Hallam-Baker, P., "Binary Encodings for JavaScript Object 2095 Notation: JSON-B, JSON-C, JSON-D", Work in Progress, 2096 Internet-Draft, draft-hallambaker-jsonbcd-18, 23 October 2097 2020, . 2100 [draft-hallambaker-mesh-cryptography] 2101 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 2102 Cryptographic Algorithms", Work in Progress, Internet- 2103 Draft, draft-hallambaker-mesh-cryptography-06, 27 July 2104 2020, . 2107 [draft-hallambaker-mesh-dare] 2108 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2109 At Rest Encryption (DARE)", Work in Progress, Internet- 2110 Draft, draft-hallambaker-mesh-dare-08, 27 July 2020, 2111 . 2114 [draft-hallambaker-mesh-developer] 2115 Hallam-Baker, P., "Mathematical Mesh: Reference 2116 Implementation", Work in Progress, Internet-Draft, draft- 2117 hallambaker-mesh-developer-10, 27 July 2020, 2118 . 2121 [draft-hallambaker-mesh-discovery] 2122 "[Reference Not Found!]". 2124 [draft-hallambaker-mesh-platform] 2125 Hallam-Baker, P., "Mathematical Mesh: Platform 2126 Configuration", Work in Progress, Internet-Draft, draft- 2127 hallambaker-mesh-platform-06, 27 July 2020, 2128 . 2131 [draft-hallambaker-mesh-protocol] 2132 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 2133 Reference", Work in Progress, Internet-Draft, draft- 2134 hallambaker-mesh-protocol-06, 27 July 2020, 2135 . 2138 [draft-hallambaker-mesh-schema] 2139 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema 2140 Reference", Work in Progress, Internet-Draft, draft- 2141 hallambaker-mesh-schema-05, 16 January 2020, 2142 . 2145 [draft-hallambaker-mesh-security] 2146 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 2147 Security Considerations", Work in Progress, Internet- 2148 Draft, draft-hallambaker-mesh-security-05, 27 July 2020, 2149 . 2152 [draft-hallambaker-mesh-udf] 2153 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 2154 Data Fingerprint.", Work in Progress, Internet-Draft, 2155 draft-hallambaker-mesh-udf-10, 27 July 2020, 2156 . 2159 [draft-hallambaker-threshold] 2160 Hallam-Baker, P., "Threshold Modes in Elliptic Curves", 2161 Work in Progress, Internet-Draft, draft-hallambaker- 2162 threshold-03, 3 September 2020, 2163 . 2166 [draft-hallambaker-threshold-sigs] 2167 Hallam-Baker, P., "Threshold Signatures in Elliptic 2168 Curves", Work in Progress, Internet-Draft, draft- 2169 hallambaker-threshold-sigs-04, 3 September 2020, 2170 . 2173 [draft-hallambaker-web-service-discovery] 2174 Hallam-Baker, P., "DNS Web Service Discovery", Work in 2175 Progress, Internet-Draft, draft-hallambaker-web-service- 2176 discovery-04, 27 July 2020, . 2179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2180 Requirement Levels", BCP 14, RFC 2119, 2181 DOI 10.17487/RFC2119, March 1997, 2182 . 2184 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2185 (TLS) Protocol Version 1.2", RFC 5246, 2186 DOI 10.17487/RFC5246, August 2008, 2187 . 2189 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 2190 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2191 2014, . 2193 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2194 (HTTP/1.1): Semantics and Content", RFC 7231, 2195 DOI 10.17487/RFC7231, June 2014, 2196 . 2198 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2199 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2200 2015, . 2202 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 2203 RFC 7516, DOI 10.17487/RFC7516, May 2015, 2204 . 2206 11. Informative References 2208 [draft-hallambaker-mesh-trust] 2209 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The 2210 Trust Mesh", Work in Progress, Internet-Draft, draft- 2211 hallambaker-mesh-trust-06, 27 July 2020, 2212 .