idnits 2.17.1 draft-hallambaker-mesh-architecture-04.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2017) is 2412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1169 -- Looks like a reference, but probably isn't: '2' on line 1172 -- Looks like a reference, but probably isn't: '3' on line 1175 -- Looks like a reference, but probably isn't: '4' on line 1178 -- Looks like a reference, but probably isn't: '5' on line 1181 -- Looks like a reference, but probably isn't: '6' on line 1184 -- Looks like a reference, but probably isn't: '7' on line 1187 -- Looks like a reference, but probably isn't: '8' on line 1190 -- Looks like a reference, but probably isn't: '9' on line 1193 ** 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) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational September 18, 2017 5 Expires: March 22, 2018 7 Mathematical Mesh: Architecture 8 draft-hallambaker-mesh-architecture-04 10 Abstract 12 The Mathematical Mesh ?The Mesh? is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The architecture of 15 the Mesh and examples of typical applications are described. 17 This document is also available online at 18 http://prismproof.org/Documents/draft-hallambaker-mesh- 19 architecture.html [1] . 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 22, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Related Specifications . . . . . . . . . . . . . . . . . 5 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. What Makes PKI Hard . . . . . . . . . . . . . . . . . . . 9 65 3.3. The Devil is in the Deployment . . . . . . . . . . . . . 10 66 3.4. The Untrusted Cloud . . . . . . . . . . . . . . . . . . . 11 67 3.5. Why change is possible . . . . . . . . . . . . . . . . . 12 68 4. Architectural Principles . . . . . . . . . . . . . . . . . . 12 69 4.1. User Centered Design . . . . . . . . . . . . . . . . . . 13 70 4.2. User Centered Trust. . . . . . . . . . . . . . . . . . . 13 71 4.3. A Credential Designed for Persistence . . . . . . . . . . 14 72 4.4. Eliminate unnecessary options . . . . . . . . . . . . . . 15 73 4.5. Strong Public Key Identifiers . . . . . . . . . . . . . . 15 74 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.1. Master and Personal Profiles . . . . . . . . . . . . . . 17 76 5.2. Device Profiles . . . . . . . . . . . . . . . . . . . . . 18 77 5.3. Application Profiles . . . . . . . . . . . . . . . . . . 19 78 5.4. Verifying Profiles . . . . . . . . . . . . . . . . . . . 19 79 5.5. Key Escrow and Recovery . . . . . . . . . . . . . . . . . 20 80 5.5.1. Offline Escrow . . . . . . . . . . . . . . . . . . . 20 81 5.5.2. Online Escrow . . . . . . . . . . . . . . . . . . . . 21 82 6. Mesh Portals and the CryptoMesh . . . . . . . . . . . . . . . 21 83 6.1. Federated Portals . . . . . . . . . . . . . . . . . . . . 22 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 89 10.2. Informative References . . . . . . . . . . . . . . . . . 25 90 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 The Mathematical Mesh is a user centered Public Key Infrastructure 96 that uses cryptography to make computers easier to use. 98 The Mesh uses cryptography and an untrusted cloud service to make 99 management of computer configuration data transparent to the end 100 user. Each Mesh user has a personal profile that is unique to them. 101 A user may link devices and applications to their Mesh profile to 102 enable transparent sharing of data between them. 104 For example, Alice has a laptop computer and a tablet. They are both 105 linked to her Mesh profile which allows either to be used for email 106 or to control any devices in her smart home. Alice has chosen to 107 only make her cloud documents available on her laptop but she could 108 change that to add her tablet should the need arise (Figure XX). 110 [[This figure is not viewable in this format. The figure is 111 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 112 architecture.html [2].]] 114 Alice's Mesh profile connections. 116 The Mesh allows devices connected to a profile to be provisioned with 117 all the network configuration settings and credentials to enable the 118 device to be used with the user's applications. In most cases, 119 public key credentials will be provisioned to enable transport layer 120 and end-to-end encryption. 122 All Mesh profiles are authenticated using digital signatures and all 123 private material protected using industry standard end-to-end 124 encryption. 126 Mesh profiles are typically published to a Mesh portal, an untrusted 127 cloud service that provides mailbox-like capabilities to enable a 128 seamless user experience for users who do not necessarily have an 129 'always on' machine to act as a broker for profile management 130 operations. Sophisticated users MAY operate a personal Mesh portal 131 should they choose. 133 Mesh portals MAY in turn be members of a federation exchanging 134 updates, thus providing users with a guarantee of continued service 135 should the portal they selected become unavailable. Each portal 136 belonging to a federation maintains a local linked hash notary log to 137 which all transactions are recorded. The outputs from each local 138 portal log are in turn periodically (e.g. once an hour) enrolled in a 139 meta-log maintained by the federation as a group. Thus ensuring that 140 no Portal belonging to a federation can defect un-noticed unless the 141 entire federation defects. 143 1.1. Document Roadmap 145 The specifications describing the Mesh protocols are divided into 146 three main groups. First set of documents describe the architecture, 147 data structures and protocols that make up the Mesh core. The second 148 set describes the use of the Mesh to secure existing and experimental 149 documents. The third set of documents describe building blocks that 150 were developed to meet requirements arising from the Mesh but are not 151 specific to the Mesh and could be applied to the development of other 152 Web Services that do not involve the Mesh. 154 Mesh Core This document provides a high level description of the 155 Mesh architecture and mode of use. Detailed specifications 156 including schemas and examples are specified in the accompanying 157 Mesh Reference document [draft-hallambaker-mesh-reference] . 159 Mesh Applications The use of the Mesh to configure mail and SSH 160 clients, and to store catalogs containing passwords, contacts and 161 bookmarks is described in [draft-hallambaker-mesh-app] . 163 The Mesh is also used as the platform for building two new 164 applications, Mesh/Recrypt [draft-hallambaker-mesh-recrypt] , and 165 Mesh/Confirm [draft-hallambaker-mesh-confirm] . 167 Mesh Platform JSON Web Service Binding 168 [draft-hallambaker-json-web-service] , Uniform Data Fingerprint 169 [draft-hallambaker-udf] , Strong Internet Names 170 [draft-hallambaker-sin] , JSON-BCD [draft-hallambaker-jsonbcd] 172 In addition, two additional documents describe the use of the 173 reference code base [draft-hallambaker-mesh-developer] and 174 recommendations for implementing Mesh enabled applications to take 175 advantage of the cryptographic facilities offered by specific 176 operating system platforms [draft-hallambaker-mesh-platform] . 178 2. Definitions 180 This section presents the related specifications and standards on 181 which the Mesh is built, the terms that are used as terms of art 182 within the Mesh protocols and applications and the terms used as 183 requirements language. 185 2.1. Related Specifications 187 Besides the documents that form the Mesh core, the Mesh makes use of 188 many existing Internet standards, including: 190 Cryptographic Algorithms Mesh applications use the cryptographic 191 algorithm suites specified by the application. The cryptographic 192 algorithms used in the Mesh itself are limited to SHA-2 [SHA-2] 193 and SHA-3 [SHA-3] digest functions, AES Encryption [FIPS197] and 194 RSA Signature, and Encryption [RFC8017] . 196 The use of the Ed25519 and Ed448 algorithms is currently being 197 explored for use with both signature [RFC8032] and encryption. 198 The Edwards Curve is preferred over the Montgomery for Encryption 199 as it affords a more straightforward implementation of techniques 200 such as co-generation of public key pairs and proxy re-encryption. 202 Transport All Mesh Services make use of multiple layers of security. 203 Protection against traffic analysis and metadata attacks are 204 provided by use of Transport Layer Security [RFC5246] . At 205 present, the HTTP/1.1 [RFC7231] protocol is used to provide 206 framing of transaction messages. 208 Encoding All Mesh protocols and data structures are expressed in the 209 JSON data model and all Mesh applications accept data in standard 210 JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and 211 Encryption [RFC7516] standards are used as the basis for object 212 signing and encryption. 214 2.2. Defined Terms 216 TBS 218 2.3. Requirements Language 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [RFC2119] . 224 2.4. Implementation Status 226 The implementation status of the reference code base is described in 227 the companion document [draft-hallambaker-mesh-developer] . 229 3. Requirements 231 Before the Web, most trade was performed in person. Mail order 232 existed but was limited in scope. Most banking transactions other 233 than withdrawing cash from an ATM had to be performed in-line at a 234 branch rather than online through the Web. Trade in stocks and shares 235 barely existed in its modern form. The TLS protocol and the WebPKI 236 that supported it enabled the e-commerce economy that we live in 237 today. 239 The WebPKI is a powerful infrastructure but it does have one major 240 drawback: It Authenticates the bank to the customer but it does not 241 authenticate the customer to the bank. The use of passwords instead 242 of strong cryptographic credentials makes users vulnerable to 243 phishing. 245 Design of a public key authentication protocol is straightforward. 246 Making the use of such a protocol practical is a much greater 247 challenge because it requires the user to manage a private key. 248 Users cannot perform even the simplest public key cryptography 249 algorithm in their head and so some sort of device must perform the 250 calculations and this in turn must be provisioned with the private 251 key. 253 Management of the server private keys for the WebPKI is challenging 254 enough and they tend to stay in one place (at least until recently). 255 Managing private keys for users is much more challenging than 256 managing server keys because: 258 o Users typically own multiple devices and expect them all to work 259 in the same way. 261 o User devices are considerably more complex than servers. They 262 have many functions. 264 o Users are more likely to lose devices or lend them to other 265 people. 267 o Users cannot be expected to be experts. 269 What has made matters worse is the notion that because users are less 270 sophisticated than system administrators, they cannot use 271 sophisticated technology. In practice, the exact opposite is the 272 case. To make the user experience completely frictionless, we must 273 embrace technologies that are more sophisticated, not avoid them. 274 Systems administrators are usually willing to accept technology that 275 is less than perfect and shows many 'rough edges' because they are 276 experts and using those tools is their job. Users are much less 277 tolerant of technology that meets their needs. 279 Modern cryptography provides us with the tools to secure practically 280 any form of Internet interaction. In almost every case, the main 281 constraint that holds us back is the impracticality of using client- 282 side private keys: 284 o OpenPGP [RFC4880] 286 o S/MIME [RFC5751] 288 o Jabber [RFC6120] 290 o IPSEC [RFC4301] 292 o SSH [RFC4251] 294 The SSH protocol supports the use of public key cryptography for 295 authentication, of course. But this is the exception that proves the 296 rule. The use of client side keys in SSH is highly effective for the 297 developer or the systems administrator who only makes use of one 298 machine as their client. Attempting to manage SSH credentials across 299 multiple client and server machines under strict operational controls 300 is not for the fait hearted. Not only is it not uncommon for users 301 to use a single private key for SSH on all the machines they use, 302 there are Web sites that 'explain' how to do this by emailing their 303 private key to themselves over SMTP. 305 From the user's perspective, a security protocol 'works' when it lets 306 them do their job in peace. The VPN access token works when they 307 gain access to the corporate network, SSH works when they gain access 308 to the server, passwords work when they can log into their bank Web 309 site and pay their bills. But when evaluating a security protocol, 310 it is equally important that the attacker is defeated and that no new 311 failure modes are introduced. The acronym C.I.A. provides a useful 312 mnemonic: 314 Confidentiality Protect data from disclosure to unauthorized 315 parties. Prevent unauthorized parties inferring confidential 316 information from traffic analysis. 318 Integrity Protect data from unauthorized modification. Establish 319 and verify data authenticity. 321 Availability Ensure that data and data services are available when 322 needed. Restrict access to authorized parties. Establish 323 accountability. 325 While Confidentiality is usually the paramount concern of users, 326 Integrity attacks almost invariably inflict more serious damage and 327 Availability attacks include some that inflict the greatest damage of 328 all. The typical consumer gets irritated if their bank carelessly 329 reveals details of their account but is considerably angrier if it 330 has been depleted by fraud. But as the recent spate of ransomware 331 attacks prove, while the consumer becomes angry when they are a 332 victim of fraud, many will actually pay money to the criminals if the 333 alternative is to lose the pictures of their grandchildren when they 334 were five. 336 Best practices for managing cryptographic keys present multiple 337 operational challenges: 339 Separation of Cryptographic Purpose Each private key SHOULD be used 340 for exactly one cryptographic function. Keys used for encryption 341 SHOULD NOT be used for authentication. Keys used to secure one 342 application SHOULD NOT be used to secure another. 344 Key Compromise Revocation of compromised keys MUST be supported. 346 Key Rotation It SHOULD be possible to periodically refresh keys used 347 to secure applications, thus ensuring that any compromise of the 348 keying material is time bounded. 350 Device Isolation Each device SHOULD have separate keys to protect 351 applications on that device. This limits the consequences should 352 the device be compromised, lost or stolen and permits revocation 353 to be limited to the keys used in that device. 355 Key Escrow Whenever a key is used to encrypt static data (i.e. data 356 stored on a disk or other storage device), provision MUST be made 357 to permit (but not require) the decryption key to be escrowed to 358 permit recovery should the need arise. 360 Provision of Key Escrow is controversial since any mechanism that 361 enables the user to recover a cryptographic key voluntarily enables 362 the user to disclose the key in case of coercion. But this state of 363 affairs, while unsatisfactory, is a lot more satisfactory than the 364 current state of affairs which is to rarely encrypt static data at 365 all. 367 3.1. Use Case 369 Alice works with Bob, Carol, and Doug. As part of her work she 370 exchanges email messages with them which may contain confidential 371 information. She also connects to the machines Server1, Server2 and 372 Server3 to perform system administration tasks. She has a personal 373 desktop, a laptop, and a tablet computer. She requires: 375 o The ability to send and receive S/MIME end-to-end encrypted email 376 with Bob and Carol as per corporate policy. 378 o The ability to send and receive OpenPGP end-to-end encrypted email 379 with Doug who does not use S/MIME. 381 o The ability to connect to Server1, Server2 and Server3 from any of 382 her personal devices. 384 o The ability to quickly configure a new device for her personal 385 use. 387 o The ability to quickly disable further use of a device should it 388 be stolen. 390 This use case is deliberately limited to configuring Alice's devices 391 to enable her to use current security protocols. A large number of 392 use cases and applications were considered during the design 393 including configuring IoT devices in Alice's home and configuring a 394 borrowed or rented device. It was discovered that considering the 395 end-to-end email case was sufficient because the requirements it 396 exposes are a superset of the requirements of the others. 398 The only use case that introduced requirements beyond Alice 399 configuring end-to-end email and SSH for herself was configuring end- 400 to-end email and other secure applications for a remote co-worker. 401 Meeting these requirements is deferred as a future work item. 403 3.2. What Makes PKI Hard 405 Every day, billions of people access Web sites using PKI encryption 406 without even being aware that they are doing so. A smaller but still 407 large number of people use PKI for secure payments, the only 408 difference they are aware of being that they insert their card rather 409 than swiping it through the reader. 411 Many of the issues that have made PKI hard in the past are due to 412 design choices taken by technologists rather than an intrinsic 413 restriction of PKI. In particular: 415 o Expiry of private keys and credentials. 417 o Poorly designed enrollment protocols. 419 o No provision for use of multiple devices. 421 o Inappropriate trust models. 423 o Intrusive user experience. 425 S/MIME and other client centered security technologies were added to 426 many Internet applications in the 1990s in response to enterprise 427 requirements. The people who make the purchasing decisions for 428 enterprise software and those who use it on a daily basis are often 429 if not invariably different, the enterprise software market has 430 prioritized functionality over usability. An email client that 431 requires the user to remember to click on the right button to encrypt 432 an email is considered acceptable in the enterprise space, it is not 433 acceptable in the consumer space. 435 While working on this project, the author attempted to configure a 436 very popular email client to make use of the built in S/MIME 437 capabilities. Even with 25 years of experience, this took over half 438 an hour and required the user to follow a procedure with 17 different 439 steps involving three different applications. Even though the 440 certificate was being issued for use with email, the user had to use 441 a Web browser to enroll for the certificate, validate the request 442 using the email client, download the certificate using the Web 443 browser and then install it using a key management tool. 445 The bar for security usability is much higher than most security 446 specialists, even those who focus on security admit. Experience 447 should teach us that the iron law of security usability is that a 448 security application that requires the user to think about security 449 will fail. 451 It is noted in passing that security usability is not achieved by 452 preventing the user seeing the information they need to make their 453 own security decisions. 455 3.3. The Devil is in the Deployment 457 One of the most important reasons for the failure of PKI applications 458 has been the failure of PKI applications. As with any communication 459 tool, the value of end-to-end secure email is a function of the size 460 of the network that can be reached. The community of S/MIME users 461 and the community of OpenPGP users have both stalled in the low 462 millions, a significant number but falling far short of ubiquity. 463 End to end secure email can only realize its full potential when its 464 use is the norm and not the vanishingly rare exception. 466 After a time, failure becomes a self-reinforcing vicious circle. 467 Very few people use end-to-end secure email applications because they 468 are difficult to use. Application providers refuse to invest in 469 developing end-to-end secure email applications because 'there is no 470 demand'. 472 The Mesh is designed for deployment by providing a stand-alone value 473 proposition to early adopters. The ability to automate the use of 474 end-to-end secure email is not a highly attractive proposition for 475 most when less than 0.1% of the Internet user population have ever 476 registered an S/MIME or OpenPGP key. But an end-to-end secure 477 password manager for Web browsers, or an SSH credential management 478 tool do provide a stand-alone value proposition. 480 3.4. The Untrusted Cloud 482 The Mesh supports multiple mechanisms for connecting devices to an 483 account. Each of these mechanisms provides for strong mutual 484 authentication of the device profile to the personal profile it is 485 being connected to and vice versa. In each case, the connection 486 request MUST be authorized by the user from a device that has already 487 been connected to the profile and granted administration privileges. 489 Figure XX shows Alice connecting a new desktop computer to her 490 profile, the connection request is initiated from the new device 491 (desktop) and approved from the administration device (tablet). 493 [[This figure is not viewable in this format. The figure is 494 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 495 architecture.html [3].]] 497 Alice connects a new device. 499 Implementing a pure peer-to-peer protocol in which the desktop and 500 tablet communicate directly would require both machines to be turned 501 on at the same time and able to communicate. Experience has shown 502 that this process is considerably more reliable when mediated by some 503 form of broker. 505 Unlike traditional cloud services that encourage users to rely on and 506 trust them to the greatest possible extent, the Mesh Portal is an 507 untrusted cloud service. The Mesh cloud cannot be breached because 508 Mesh cloud does not guarantee confidentiality, or integrity or 509 availability. 511 There are three main functions that a Mesh Portal MAY perform: 513 o Acts as a mailbox to which connection requests and responses are 514 posted. 516 o Acts as an intermediary to third party trust providers. 518 o Acts as an intermediary to credential publication services. 520 Only the first of these functions is required. But the protocol 521 requirements for meeting the requirements of the first makes the 522 other two a natural fit. 524 3.5. Why change is possible 526 All four of the open standards based PKIs that have been developed in 527 the IETF are based on designs that emerged in the mid-1990s. 528 Performing the computations necessary for public key cryptography 529 without noticeable impact on the speed of user interaction was a 530 constraint for even the fastest machines of the day. Consequently, 531 PKI designs attempted to limit the number of cryptographic operations 532 required to the bare minimum necessary. There were long debates over 533 the question of whether certificate chains of more than 3 534 certificates were acceptable. 536 Today a 32-bit computer with two processing cores running at 1.2GHz 537 can be bought for $5 and public key algorithms are available that 538 provide a higher level of security than was achievable in the 1990s 539 for less computation time. In 1995, the idea that a single user 540 might need a hundred public key pairs and a personal PKI to manage 541 them as an extreme scenario. Today when the typical user has a 542 phone, a tablet and a laptop and their home is about to fill up 543 dozens if not hundreds of network connected devices, the need to 544 manage large numbers of keys for individual users is clear. 546 Use of public key cryptography on the scale used in the Mesh would 547 have been impractical even for financial applications as recently as 548 15 years ago. Today, the performance and memory overhead is 549 negligible. 551 4. Architectural Principles 553 Over the course of the first quarter century of commercial use of 554 PKI, a consensus has emerged as to the principles of robust protocol 555 design; All aspects of the design should be public, all cryptographic 556 algorithms should be open standards that have been widely reviewed by 557 domain experts, etc. 559 The Mathematical Mesh is appropriately aligned with this established 560 consensus but departs from existing practice in certain areas as set 561 out in the following. 563 4.1. User Centered Design 565 Traditional enterprise centered PKI keeps the enterprise (and to an 566 extent the users) secure but only as long as the users follow a long 567 list of often complex instructions. Even the US National Security 568 Agency, an institution whose core competence is cryptography and 569 whose principle purpose is to protect US government information 570 failed to protect some of its greatest secrets because it was just 571 too hard to use the right cryptography. 573 A key principle that guides the design of the Mesh is that any set of 574 instructions that can be written down and given to a user can be 575 written down as code and executed by the computer. Public key 576 cryptography is used to automate the process of managing public keys. 577 Instead of telling the user how to register for a certificate and 578 install it in their mail client, we tell the computer how to do the 579 task for them. 581 4.2. User Centered Trust. 583 One of the principal ideological battles that has been fought in the 584 development of end-to-end email security has been the manner in which 585 trust is provided. In the S/MIME protocol, trust is established 586 through a hierarchy of trust providers. In the OpenPGP protocol, 587 trust is in theory established through a 'Web of Trust' but is in 588 practice almost invariably established through either a direct trust 589 model (exchange of key fingerprints) or on a trust after first use 590 basis. 592 Perhaps, what we should be willing to learn from the experience of 593 attempting to apply these models to real world applications is that 594 none is sufficient by itself. Rather than attempting to impose a 595 single model of trust on every circumstance, multiple trust models 596 should be supported. 598 The trust model appropriate for validating a key depends on the 599 context in which it is to be used. If Alice is sending Bob a 600 personal email, it is likely that the best key to use will be the one 601 that matches the key fingerprint from the business card he gave her 602 when they met in person. But when Alice is sending Bob an email as 603 her stockbroker, the best key is going to be the one that is issued 604 to Bob as an employee of the brokerage company. 606 Any trust model must be built around the needs of the user. The Mesh 607 does not impose a model for mapping human to machine interaction 608 identifiers but it does allow the user to put that mapping under 609 their personal control. Devices connected to a Mesh Personal Profile 610 share the same view of the world; the same set of bookmarks and 611 contacts for defining personal names and the same set of trust roots 612 for Certification Authorities trusted to provide brokered trust. 614 In the traditional model, PKI is used to validate network hosts after 615 discovery. The credential issued by the CA is verified each time the 616 user visits the site. 618 [[This figure is not viewable in this format. The figure is 619 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 620 architecture.html [4].]] 622 Traditional PKI role. 624 In the Mesh trust model, the primary role of the CA is to provide 625 introductions. When the user first visits the site, to buy goods, 626 the site (and often the vendor it belongs to) is unknown. At this 627 point, the user is looking to the Authority to help decide if they 628 wish to purchase from. 630 [[This figure is not viewable in this format. The figure is 631 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 632 architecture.html [5].]] 634 Trusted Authority as Introducer 636 Once users can easily maintain a personal directory of trusted 637 vendors and share it across all the devices they use, their personal 638 trust directory becomes their primary trust provider. Thus, the role 639 of the authority changes once a trust relationship has been 640 established from trust provider to trust revoker. The user does not 641 need the authority to tell them to trust a vendor they are already 642 doing business with but they may need the authority to warn them if 643 the vendor has defaulted on purchases made by other customers or has 644 suffered a major breach, etc. 646 4.3. A Credential Designed for Persistence 648 One of the main difficulties in using S/MIME for email security is 649 that many users stop using the system when their certificate expires. 650 It is likely that one of the main reasons that OpenPGP is more 651 popular amongst system administrators is that a maintenance-free user 652 experience is available to anyone who decides to neglect key 653 rollover. 655 A Mesh Master Profile fingerprint is designed to provide a user with 656 a credential that can be used for a lifetime. Using the same 657 offline/online key management approaches that have been applied to 658 root key management in the WebPKI since it began provides users with 659 a credential with a cryptographic lifetime of 20-30 years. The 660 addition of linked notary log technology in the Mesh Portals allows 661 such credentials to be securely renewed should the need arise and 662 thus enabling indefinite use. 664 4.4. Eliminate unnecessary options 666 Traditionally cryptographic applications give the user a bewildering 667 choice of algorithms and options. They can choose to have one RSA 668 keypair used for encryption and signature or they can have separate 669 keys for both, they can encrypt their messages using 3DES or AES at 670 128, 192 or 256 bit security. And so on. 672 The Mesh eliminates such choices as unnecessary. Except where 673 required by an application, the Mesh always uses separate keys for 674 encryption and signature operations and only uses the highest 675 strength on offer. Currently, Mesh profiles are always encrypted 676 using RSAES-PKCS1-v1_5 with a 2048 bit key [RFC8017] , AES with a 256 677 bit key [FIPS197] and SHA-2-512 [SHA-2] . The use of RSA 2048 will be 678 replaced with Ed448 [RFC8032] when sufficiently mature 679 implementations become available. 681 For similar reasons, every Mesh master profile has an escrow key. 682 The use of key escrow by applications is optional, but every profile 683 has the capability of using it should circumstances require. 685 4.5. Strong Public Key Identifiers 687 A key departure from traditional PKI approaches is that all 688 cryptographic keys are identified in every circumstance by either the 689 UDF fingerprint of the public key in the case of a public key pair or 690 the UDF fingerprint of the symmetric key in the case of a symmetric 691 key pair. No other form of key identifier is used. 693 This approach greatly simplifies the processes of key discovery, 694 management and signature verification. 696 Since a UDF fingerprint of sufficient length, uniquely identifies a 697 public key pair, it follows that if the attempt to verify the 698 signature under a public key whose fingerprint matches that specified 699 returns the result false, that the signature is invalid. Contrawise, 700 if the result returned is true, the data is validly signed for a 701 given purpose if and only if the key identifier is authorized for 702 that purpose. 704 5. Architecture 706 All information exchanged through the Mesh is described in a profile. 707 Profiles have the following properties. 709 o Profiles are first class objects with a unique, immutable 710 identifier that either is or contains a UDF fingerprint of a 711 signature key 713 o All profiles are digitally signed. 715 o Profiles are encoded in JSON [RFC7159] . 717 At present, four types of Mesh Profile are defined: 719 Master Profile Describes the criteria for validating a user's 720 personal profile. 722 Personal Profile Describes the user's personal Trust Mesh, the set 723 of device and application profiles connected to it. 725 Application Profile Describes the use of a particular application. 727 Device Profile Describes a device and cryptographic keys specific to 728 that device. 730 A profile is Valid if and only if it is Verified, Current and 731 Correct: 733 Verified A signature is verified if the key identifier specified 734 maps to a 736 Current A profile is current if and only if it has not been 737 superseded by a new profile published to the Mesh Portal. 739 Correct A profile is correct if the signing key identifier specified 740 in the signature data is a legitimate signing key for that type of 741 profile as specified in Section YY below. 743 A profile is connected to a personal profile if and only if: 745 o The Personal Profile contains an entry for its profile identifier 746 that is consistent with the profile type. 748 o The Personal Profile is Valid. 750 o The Application Profile is Valid. 752 This trust model allows Application Profiles and Device Profiles to 753 be connected to a Personal Profile by enumerating the identifiers of 754 the connected profile in the personal profile. 756 [[This figure is not viewable in this format. The figure is 757 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 758 architecture.html [6].]] 760 A Master/Personal Profile connected to Application and Device 761 profiles. 763 5.1. Master and Personal Profiles 765 Each Mesh user has a Master Profile and a Personal Profile. 767 Personal Profile Contains a list of all the device profiles and 768 application profiles that are currently connected to the user's 769 personal Mesh. The personal profile is signed by an 770 administrative key. 772 Master Profile Contains a list of administrative keys used to sign 773 personal profiles and the master signature key used to sign the 774 Master Profile. 776 The use of master signature keys and administration keys to 777 authenticate the Master and Personal profiles needs further 778 explanation. 780 [[This figure is not viewable in this format. The figure is 781 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 782 architecture.html [7].]] 784 Master and Personal Profile Signature 786 This separation allows the user to add devices and/or change 787 application settings frequently without the need for changes to their 788 master profile or to access their master signature key. This allows 789 the master signature key to be stored in a safe place, preferably 790 using a Hardware Security Module or other precautions without the 791 inconvenience this would entail if regular use of the key was 792 required. 794 A typical user might modify their personal profile hundreds of times 795 over their lifetime, conceivably even more in a world where homes are 796 filled with hundreds of IoT devices. Adding or removing 797 administrative devices is likely to occur much less frequently. The 798 master signature key used to authenticate the Master Profile never 799 changes. If it becomes necessary to replace the master signature 800 key, it will be necessary to create a new Master profile and perform 801 a secure transition to the new key. 803 Since the master signature key does not change by definition, the 804 fingerprint of the master signature key is a persistent identifier 805 that will remain constant and only ever refer to exactly one Master 806 Profile. Furthermore, since at any given time a Master Profile has 807 exactly one Personal Profile attached to it (and vice versa), the 808 fingerprint of the master signature key is a persistent identifier 809 for the Personal Profile as well. 811 5.2. Device Profiles 813 A device profile contains a description of the device and the public 814 keys to be used as the basis for encryption, authentication and 815 signature on that device (Figure XXX). Ideally, the private keys 816 associated with the device are generated using a secure procedure on 817 the device itself and are bound to the device so that they cannot be 818 exported from it. 820 [[This figure is not viewable in this format. The figure is 821 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 822 architecture.html [8].]] 824 Device Profile 826 Application profiles MAY specify additional profiles to be used with 827 a particular device for an application specific purpose. 829 While it is usually desirable for such keys to be generated on the 830 device itself, this is not always possible. If, for example, the 831 application profile is connected to a personal profile with multiple 832 existing devices. In this circumstance, the use of a co-operative 833 key generation approach [PHB-CoKey] is preferred but not always 834 possible. If no other options are available, additional application 835 private keys may be provisioned to the device by encrypting them 836 under the device private key. 838 Device profiles are connected to a personal profile by enumerating 839 them in the Personal Profile. 841 5.3. Application Profiles 843 An application profile describes the configuration of an application. 844 An Application Profile MAY contain: 846 Public data Information that is intended for public use that applies 847 to all devices. For example, the user's public encryption key for 848 end to end secure email. 850 Private Data Information that applies to all devices that is only 851 intended for use by connected devices. For example, the network 852 configuration information describing how to access the inbound and 853 outbound mail servers. 855 Public Per Device Data Information that is intended for public use 856 that applies to a specific device. For example, the user's public 857 signature key might be different for each device. 859 Private Per Device Data Information that applies to a specific 860 device and is only for the use of that device. For example, a 861 per-device signature key. 863 Application Profiles are connected to a Personal Profile by an 864 Application Device Entry. The Application Device Entry specifies the 865 identifier of the device and the set of privileges delegated to it 866 with respect to that application. These privileges MAY include the 867 privilege of signing Application Profile updates. This allows a 868 device that is not an administration device for the personal profile 869 to be permitted to update the application profile. Thus, Alice might 870 not want her laptop to be an administration device but would likely 871 want to be able to add or update Web Site usernames and passwords. 873 5.4. Verifying Profiles 875 As described in section XXX, the key identifier in a Mesh Profile 876 signature is the UDF fingerprint of the public key to be used for 877 verification. Therefore, a Profile is invalid if either: 879 Attempting to validate the profile under a public key whose UDF 880 fingerprint matches that specified in the key identifier returns the 881 result false. 883 The Key Identifier specified in the signature is not explicitly 884 authorized for the purpose as described below. 886 The Key Identifiers authorized to sign a profile depend on the type 887 of profile as follows: 889 Master Profile The Key Identifier of the key that signs the profile 890 MUST be the UDF fingerprint of the Master Signature Key specified 891 in that Master Profile. 893 Personal Profile The Key Identifier of the key that signs the 894 profile MUST be listed as the identifier of an Administrator Key 895 specified in the corresponding Master Profile. 897 Device Profile The Key Identifier of the key that signs the profile 898 MUST be the UDF fingerprint of the Device Signature Key specified 899 in that Device Profile. 901 Application Profile The Key Identifier of the key that signs the 902 profile MUST be listed as the identifier of an Administrator key 903 for that Application Profile in the corresponding Personal 904 Profile. 906 5.5. Key Escrow and Recovery 908 Key Escrow and Recovery capabilities are built into the core of the 909 Mesh. Use of these capabilities is RECOMMENDED but not required. 911 Encryption of stored data such as email messages and personal 912 photographs protects confidentiality but introduces a major 913 availability risk: The data will be lost if the user loses access to 914 the decryption key. While the risk of being coerced into disclosure 915 of material is a risk for some users, availability is a concern for 916 all users. 918 The Mesh supports two types of key escrow, Offline and Online. 920 Offline Key Escrow Is used to escrow Master Signature Keys, Master 921 Escrow Keys and other private keys that are particularly important 922 to a user and are to be preserved. 924 Online Key Escrow Is used to protect all other keys by escrowing the 925 key under a Master Escrow Key. 927 5.5.1. Offline Escrow 929 The use of Shamir Secret Sharing [ShamirXX] to escrow private keys is 930 supported as follows: 932 o A 256 bit random session key is generated. 934 o The private key and related data is encrypted under the session 935 key to form the key escrow data blob. 937 o The unique identifier for the key escrow data blob is the UDF 938 fingerprint of the session key. 940 o The key escrow data blob is stored in some form of persistent 941 storage that is believed to provide a very high degree of 942 availability. 944 o The session key is split into n of m shares using Shamir secret 945 sharing. 947 Since the purpose of the Mesh Portal is in part to provide a high 948 availability data storage facility, the use of the Mesh to store the 949 key recovery blob is preferred. 951 Data recovery is the reverse of the escrow process: 953 o The shared secret is recovered from at least n of the key shares. 955 o The unique identifier for the key escrow data blob is calculated 956 from the session key 958 o The unique identifier is used to retrieve the key recovery blob. 960 o The key recovery blob is decrypted using the session key. 962 It will be noted that this process is anonymous. The key recovery 963 blob does not identify the profile or user to which it refers in any 964 way. 966 5.5.2. Online Escrow 968 Support for Online escrow requires only that decryption keys for 969 application use be encrypted under the master escrow key as if it was 970 another device connected to a Personal Profile. 972 6. Mesh Portals and the CryptoMesh 974 As described earlier, a Mesh Portal is an untrusted cloud services 975 that facilitates the management of Mesh profiles by providing 976 persistent storage. A personal profile MAY be registered to one, 977 many or no Mesh Portals at a time. 979 For the sake of convenience and familiarity, the Mesh Portal Protocol 980 makes use of account identifiers in the traditional [RFC5322] format 981 @. Transactions supported by the Portal Protocol 982 include: 984 o Create Account 985 o Add profile 987 o Update profile 989 o Request device connection* 991 o View pending requests* 993 o Accept or reject a connection request* 995 Transactions marked with an asterisk* require administration 996 privileges for the personal profile. 998 Although the Mesh Architecture regards the Mesh Portal to be an 999 untrusted cloud service with respect to Confidentiality and 1000 Integrity, the information transferred between devices and the portal 1001 could be susceptible to traffic analysis. For this reason, all 1002 exchanges between devices and the portal MUST be protected using a 1003 transport layer security enhancement such as TLS [RFC5246] . 1005 6.1. Federated Portals 1007 A Mesh Portal MAY belong to a Federation. Portals belonging to a 1008 Federation periodically synchronize their transaction logs so that 1009 all the members of the federation have access to the complete set of 1010 transaction logs for all the portals belonging to the federation. 1011 This allows the federation to collectively guarantee the availability 1012 of the user's profile data should one or more portals become 1013 unavailable either temporarily or permanently. 1015 The InterMesh protocol is supports Portal Federation. 1017 The CryptoMesh is proposed open federation of Mesh Portals that 1018 permits any portal willing to accept its terms of service to join. 1019 Due to the nature of the network effect it is expected that there 1020 would be only one such open federation baring major disagreements as 1021 to terms of service. Figure XXX 1023 [[This figure is not viewable in this format. The figure is 1024 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 1025 architecture.html [9].]] 1027 The Cryptomesh. 1029 Mesh Portals that are a member of a Federation have a mutual 1030 responsibility to protect availability by acting to mitigate abuse by 1031 users attempting to create excessive numbers of profiles or perform 1032 excessive numbers of updates. 1034 7. Security Considerations 1036 NYI 1038 8. IANA Considerations 1040 This document does not contain actions for IANA 1042 9. Acknowledgements 1044 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1045 Alden. 1047 10. References 1049 10.1. Normative References 1051 [draft-hallambaker-json-web-service] 1052 Hallam-Baker, P., "JSON Web Service Binding Version 1.0", 1053 draft-hallambaker-json-web-service-07 (work in progress), 1054 September 2017. 1056 [draft-hallambaker-jsonbcd] 1057 Hallam-Baker, P., "Binary Encodings for JavaScript Object 1058 Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- 1059 jsonbcd-08 (work in progress), September 2017. 1061 [draft-hallambaker-mesh-app] 1062 "[Reference Not Found!]". 1064 [draft-hallambaker-mesh-confirm] 1065 Hallam-Baker, P., "Mesh Confirmation Protocol (Mesh/ 1066 Confirm)", draft-hallambaker-mesh-confirm-01 (work in 1067 progress), August 2017. 1069 [draft-hallambaker-mesh-developer] 1070 Hallam-Baker, P., "Mathematical Mesh: Reference 1071 Implementation", draft-hallambaker-mesh-developer-04 (work 1072 in progress), September 2017. 1074 [draft-hallambaker-mesh-platform] 1075 Hallam-Baker, P., "Mathematical Mesh: Platform 1076 Configuration", draft-hallambaker-mesh-platform-00 (work 1077 in progress), September 2016. 1079 [draft-hallambaker-mesh-recrypt] 1080 Hallam-Baker, P., "Mesh/Recrypt: Usable Confidentiality", 1081 draft-hallambaker-mesh-recrypt-02 (work in progress), 1082 August 2017. 1084 [draft-hallambaker-mesh-reference] 1085 Hallam-Baker, P., "Mathematical Mesh: Reference", draft- 1086 hallambaker-mesh-reference-06 (work in progress), 1087 September 2017. 1089 [draft-hallambaker-sin] 1090 Hallam-Baker, P., "Strong Internet Names (SIN)", draft- 1091 hallambaker-sin-00 (work in progress), August 2017. 1093 [draft-hallambaker-udf] 1094 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 1095 hallambaker-udf-06 (work in progress), August 2017. 1097 [FIPS197] "[Reference Not Found!]". 1099 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1100 Requirement Levels", BCP 14, RFC 2119, 1101 DOI 10.17487/RFC2119, March 1997. 1103 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1104 (TLS) Protocol Version 1.2", RFC 5246, 1105 DOI 10.17487/RFC5246, August 2008. 1107 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1108 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1109 2014. 1111 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1112 (HTTP/1.1): Semantics and Content", RFC 7231, 1113 DOI 10.17487/RFC7231, June 2014. 1115 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1116 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1117 2015. 1119 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1120 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1122 [RFC8017] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch, 1123 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1124 RFC 8017, DOI 10.17487/RFC8017, November 2016. 1126 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1127 Signature Algorithm (EdDSA)", RFC 8032, 1128 DOI 10.17487/RFC8032, January 2017. 1130 [SHA-2] NIST, "Secure Hash Standard", August 2015. 1132 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 1133 Extendable-Output Functions", August 2015. 1135 [ShamirXX] 1136 "[Reference Not Found!]". 1138 10.2. Informative References 1140 [PHB-CoKey] 1141 "[Reference Not Found!]". 1143 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1144 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 1145 January 2006. 1147 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1148 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1149 December 2005. 1151 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1152 Thayer, "OpenPGP Message Format", RFC 4880, 1153 DOI 10.17487/RFC4880, November 2007. 1155 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1156 DOI 10.17487/RFC5322, October 2008. 1158 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1159 Mail Extensions (S/MIME) Version 3.2 Message 1160 Specification", RFC 5751, DOI 10.17487/RFC5751, January 1161 2010. 1163 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1164 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1165 March 2011. 1167 10.3. URIs 1169 [1] http://prismproof.org/Documents/draft-hallambaker-mesh- 1170 architecture.html 1172 [2] http://prismproof.org/Documents/draft-hallambaker-mesh- 1173 architecture.html 1175 [3] http://prismproof.org/Documents/draft-hallambaker-mesh- 1176 architecture.html 1178 [4] http://prismproof.org/Documents/draft-hallambaker-mesh- 1179 architecture.html 1181 [5] http://prismproof.org/Documents/draft-hallambaker-mesh- 1182 architecture.html 1184 [6] http://prismproof.org/Documents/draft-hallambaker-mesh- 1185 architecture.html 1187 [7] http://prismproof.org/Documents/draft-hallambaker-mesh- 1188 architecture.html 1190 [8] http://prismproof.org/Documents/draft-hallambaker-mesh- 1191 architecture.html 1193 [9] http://prismproof.org/Documents/draft-hallambaker-mesh- 1194 architecture.html 1196 Author's Address 1198 Phillip Hallam-Baker 1199 Comodo Group Inc. 1201 Email: philliph@comodo.com