idnits 2.17.1 draft-hallambaker-cryptomesh-00.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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 723 has weird spacing: '...) where is th...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Currently the architecture of the Mesh is in a state of rapid change. Users SHOULD not therefore rely on the security considerations set out in this document without first checking to see if the instance of the mesh they are connecting to follows the version of the mesh protocols to which they refer. -- The document date (June 29, 2015) is 3222 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 119 looks like a reference -- Missing reference section? 'Public' on line 850 looks like a reference -- Missing reference section? 'Signed' on line 560 looks like a reference -- Missing reference section? 'Private' on line 854 looks like a reference -- Missing reference section? 'Gateway' on line 881 looks like a reference -- Missing reference section? 'Distribution' on line 881 looks like a reference Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 INTERNET-DRAFT Comodo Group Inc. 3 Intended Status: Standards Track June 29, 2015 4 Expires: December 31, 2015 6 Modular Mathematical Mesh 7 draft-hallambaker-cryptomesh-00 9 Abstract 11 The Magic Mathematical Mesh 'the Mesh' is a security infrastructure 12 for the Internet that puts individual users in control of their 13 security. Through large scale redundancy and replication techniques, 14 mesh users have a high level of assurance that data stored in the 15 mesh through a mesh gateway node will be available at a later date. 17 The mesh does not offer confidentiality guarantees. All data in the 18 mesh is assumed to be public. Confidential data stored in the mesh 19 must be protected using strong encryption. The mesh provides a medium 20 that enables the exchange of private key data but never passes 21 private data of any form in plaintext form. 23 The mesh enables use of end-to-end and transport security with mutual 24 authentication in a wide range of client server and peer-peer 25 applications. These include email, remote access and the Web. Unlike 26 previous attempts to establish such infrastructures, the password 27 management application supported by the mesh delivers users with an 28 immediate benefit that does not rely on adoption by others. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. What does the Mesh do for me? . . . . . . . . . . . . . . 7 67 2.1.1. User Experience . . . . . . . . . . . . . . . . . . 8 68 2.1.2. What else can the Mesh do for me in the future? . . 9 69 2.2. No-Password Authentication . . . . . . . . . . . . . . . 10 70 2.3. Encrypted Email . . . . . . . . . . . . . . . . . . . . . 10 71 2.4. WiFi and Networking . . . . . . . . . . . . . . . . . . . 11 72 2.5. Internet of Things . . . . . . . . . . . . . . . . . . . 11 73 2.6. Developer Tools . . . . . . . . . . . . . . . . . . . . . 12 74 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.1. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.1.1. Personal Profile . . . . . . . . . . . . . . . . . . 13 77 3.1.2. Device Profile . . . . . . . . . . . . . . . . . . . 15 78 3.2. Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 3.2.1. Offline Escrow . . . . . . . . . . . . . . . . . . . 16 80 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16 81 3.3.1. Object Identifiers . . . . . . . . . . . . . . . . . 16 82 3.3.2. Account Identifier . . . . . . . . . . . . . . . . . 17 83 3.3.3. Profile Identifier URI . . . . . . . . . . . . . . . 17 84 4. Application Profiles . . . . . . . . . . . . . . . . . . . . . 18 85 4.1. Administration . . . . . . . . . . . . . . . . . . . . . 18 86 4.2. Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.3. Network Connection . . . . . . . . . . . . . . . . . . . 18 88 4.4. Password Manager . . . . . . . . . . . . . . . . . . . . 19 89 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 19 90 4.6. Email . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 5. Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . 20 92 5.1. Mesh Log . . . . . . . . . . . . . . . . . . . . . . . . 21 93 5.2. Mesh Replication . . . . . . . . . . . . . . . . . . . . 21 94 6. Requirements and Recommendations . . . . . . . . . . . . . . . 21 95 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21 96 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 22 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 7.1. Mesh Integrity . . . . . . . . . . . . . . . . . . . . . 22 99 7.2. Mesh Data Confidentiality . . . . . . . . . . . . . . . . 22 100 7.3. Disclosure of Private Key . . . . . . . . . . . . . . . . 23 101 7.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 23 102 7.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23 103 7.6. Covert Channels . . . . . . . . . . . . . . . . . . . . . 23 104 7.7. Data Loss . . . . . . . . . . . . . . . . . . . . . . . . 24 105 7.8. User Capture . . . . . . . . . . . . . . . . . . . . . . 24 106 8. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 24 107 8.1. Registration of mmm URI Scheme (provisional) . . . . . . 24 108 8.2. Registration of application/mesh Content Types . . . . . 24 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 1. Definitions 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 1.2. Defined Terms 122 Mesh Object 123 A collection of data items stored in the mesh with a unique 124 and fixed identifier. 126 Mesh Entry 127 An entry in the mesh recording the value of a mesh object at 128 a particular instant. 130 Profile 131 A mesh object that contains 133 Personal Profile 134 A profile that contains a description of a user?s personal 135 PKI, credentials and connected devices and applications. 137 Device Profile 138 A profile that contains a description of a device and its 139 associated credentials. 141 Application Profile 142 A profile that contains a description of the use of an 143 application by a user 145 Enterprise Profile 146 A profile that contains a description of a enterprise?s PKI, 147 credentials and connected devices and applications. 149 Mesh Node 150 One or more host machines that provide mesh services under 151 the same domain name and share the same state. 153 Gateway Node 154 A Mesh node that supports services that append data to the 155 Mesh. 157 Distribution Node 158 A Mesh node that supports services that report but do not 159 change the state of the Mesh. 161 Mesh 162 A collection of interlinked Mesh Nodes exchanging data 163 through the replication protocol so as to present a single 164 consistent repository for all mesh 166 Public Key 167 Non-secret portion of a public key pair. 169 Private Key 170 Secret portion of a public key pair. 172 Fingerprint 173 The output of a cryptographic digest function presented in a 174 form that facilitates verification that the original data 175 input is unchanged. 177 Public Profile 178 A profile or portion of a profile containing plaintext data. 180 Private Profile 181 A profile or portion of a profile containing encrypted data. 183 2. Introduction 185 The Magic Mathematical Mesh 'the Mesh' is a security infrastructure 186 for the Internet that puts individual users in control of their 187 security. The Mesh is based on three principles: 189 Magic 190 From the point of view of the user, the mesh should appear 191 to work 'by magic'. Visiting a Web site secured using https 192 requires no more effort from the user than visiting an 193 insecure site. That principle of 'security by magic' should 194 apply to every interaction. 196 Mathematical 197 The mesh provides security through the use of cryptography. 198 Users do not need to understand the mathematics that make 199 the mesh work but every part of the mathematics supporting 200 the mesh must be public and fully documented. 202 Mesh 203 The mesh itself is a decentralized cloud service similar to 204 the blockchain that supports BitCoin. Like the services that 205 support the blockchain, every operation on the mesh is 206 public and the integrity of the mesh is preserved by means 207 of a hash chain mechanism. The mesh does not store or have 208 access to any confidential plaintext data of any kind 209 including private keys. Once information has been replicated 210 across the surface of the mesh, it cannot be deleted without 211 the collusion of every mesh node and without the originator 212 being able to detect the default. 214 While constructing such an infrastructure would have been considered 215 an absurd challenge in 1995, the success of BitCoin provides a 216 demonstration that deploying infrastructures of this size is now both 217 practical and possible. 219 The indexed Web contains over 4.6 billion pages and 5 zettabytes of 220 data and both are growing at an exponential rate. To serve its 221 function, the mesh need only store a personal profile of a few tens 222 of kilobytes for each person on the planet. A single desktop RAID 223 array could store a personal profile for every one of the three 224 billion users of the Web today. 226 2.1. What does the Mesh do for me? 228 Today the World Wide Web has thousands of uses from information 229 retrieval to online banking to turning light switches on and off in 230 the home. But the original success of the Web at CERN was came from 231 serving just one function and doing that very well: Providing access 232 to the CERN phoned directory. 234 Today's Internet users have myriad security desires and even greater 235 needs. They want encrypted mail; they want encrypted documents; they 236 want encrypted Web sites. But the single biggest security related 237 aggravation is the need to remember usernames and passwords for 238 hundreds of individual Web Sites. Attempts to solve this problem to 239 date have focused on two particular strategies: 241 * Persuade users to store all their passwords in a network 242 accessible service. 244 * Persuade Web site providers to use an external 'identity 245 service' to perform account management for them. 247 Both approaches have major flaws as the recent breach at LastPass and 248 Google's decision to drop support for OpenID 2.0 demonstrate. If a 249 Web Site decides to outsource identity management to a third party 250 they are making their business dependent on that third party 251 operating their infrastructure securely and continuing to do business 252 in a particular way. 254 Storing account credentials in the mesh overcomes the problems 255 associated with both legacy approaches: 257 * The mesh is not a trusted service. The mesh cannot be 258 breached because the mesh does not offer any security 259 guarantees. The security of mesh applications depends on the 260 security of the end points, not the security of the mesh. 262 * All data stored in the mesh is encrypted, including 263 usernames and passwords. 265 * Decrypting data stored in the mesh always requires 266 information stored outside the mesh. 268 * The mesh is not a restricted service. Anyone can set up a 269 mesh at any time and anyone can distribute an established 270 public mesh. 272 * Mesh users connect through a mesh gateway. By definition, a 273 public mesh has multiple gateway providers and can change 274 their gateway at any time. 276 * Mesh users can always recover the information assets they 277 stored, either from local storage or from a mesh 278 distributor. 280 * The only necessary requirement for a mesh gateway is to 281 impose some form of abuse limiting mechanism to stop denial 282 of service attack against the mesh by flooding it with bogus 283 data. 285 Although the primary purpose of this proposal is to establish a 286 single cryptomesh as a ubiquitous public infrastructure analogous to 287 the Internet, DNS and the WebPKI, it is recognized that such 288 infrastructures are more likely to grow organically rather than 289 through a top-down approach. Reflecting this approach, the mesh is 290 conceived as a collection of loosely coupled nodes, each of which is 291 independently hosted and operated. 293 A mesh gateway node may assure users that their data is protected in 294 the event of a permanent or temporary loss of service at that node by 295 establishing replication agreements with one or more independent 296 nodes. Such agreements may be reasonably expected to encourage the 297 emergence of a single public mesh over time. 299 2.1.1. User Experience 301 A personal profile is created using the profile management tool. In 302 quickstart mode the user need provide nothing more than an account 303 name for the profile and the domain of a mesh gateway (e.g. 304 comodo.com). Even the account name is not strictly necessary unless 305 the user has more than one profile. It just proved easier for users 306 to ask than making this an option. The second can be given by default 307 with a user override option. 309 Whenever a new profile is created, the profile manager reports a 310 profile fingerprint. This is conceptually similar to an OpenPGP key 311 but with the important distinction of not being limited to a single 312 application. Once a profile is generated, its fingerprint never 313 changes. The profile fingerprint is used when connecting new devices 314 to a profile to ensure that the correct device is being connected and 315 not an impostor. While at present fingerprints are Base32 encoded 316 alphanumeric strings, other formats such as a sequence of images may 317 be used for verification. 319 Since a new profile does not contain any data at all, the user may 320 skip the key escrow option. Otherwise the master signature and 321 decryption keys for the profile are encrypted under a symmetric key 322 and stored in a private profile. The symmetric key is then split 323 using Shamir secret sharing and each share presented to the user as 324 an alphanumeric recovery key and/or QR code. These may be printed and 325 stored in case recovery should be required. 327 Once a profile has been established, a mesh enabled application 328 running on the same device may use it automatically or after 329 requesting user consent. Thus a mesh enabled password manager might 330 prompt the user to ask if they wanted to store usernames and 331 passwords in their mesh profile. 333 To make use of an existing profile on a second device, a user starts 334 the profile manager and gives the account name. The profile manager 335 displays the profile fingerprint for verification purposes. When the 336 user runs the profile manager on a machine that has been connected to 337 the profile already and granted administration privileges, it 338 displays a list of pending connection requests which may be approved 339 or declined as the user decides. Once the request is approved, the 340 user will have full access to their passwords stored in the crypto 341 mesh on the second machine. 343 Even though the user experience of a mesh based password manager is 344 no more complicated than that of a traditional scheme, no 345 confidential data is ever passed unencrypted through the mesh and all 346 encryption is end to end and uses the strongest level of AES 347 encryption. The mesh is thus immune to the risk of breach since there 348 is no information to be breached. 350 More importantly, once a user has made the effort of installing a 351 mesh profile manager, they have the tools at their disposal to use 352 the mesh with any application that is mesh-enabled. By design, the 353 mesh supports any application that uses cryptographic credentials. 355 2.1.2. What else can the Mesh do for me in the future? 357 Use of the Web at CERN began with the phone book. But that use alone 358 would not have been enough to justify the effort of developing the 359 tool. The reason CERN was willing to invest the time and effort 360 required to build the Web was the understanding that it would one day 361 be capable of doing much more. 363 While the CERN phone book was the 'killer application' of the Web on 364 CERN main site, the Web itself was originally designed to enable 365 distribution of research materials. In the same way, secure password 366 storage represents a 'killer application' that requires no other 367 party to buy-in or make use of the mesh in order to build out the 368 infrastructure. But it is sincerely hoped that once that 369 infrastructure is established it will enable second generation 370 applications that are far more useful. 372 The mesh provides a mechanism for storing and retrieving profiles. In 373 this paper we only consider the profile types relevant to one 374 particular mesh, the cryptographic mesh (cryptomesh) used to store 375 cryptographic credentials and other data relevant to enabling use of 376 applications. Since strong cryptographic keys need only be tens or 377 hundreds of bytes, such profiles would typically be very small, a few 378 tens or hundreds of kilobytes at most. But given suitable storage 379 capability, the same technology used to build the cryptomesh could 380 also be applied to storage of data (aka the datamesh). 382 2.2. No-Password Authentication 384 Making passwords easier to use is good. But the getting rid of them 385 entirely is better. There is no little irony in the fact that after 386 rendering the telephone book obsolete, the Internet quickly rendered 387 the public telephone network obsolete. It would be the greatest 388 service if the mesh could render passwords obsolete as a network 389 authentication mechanism. 391 There is no shortage of protocols and mechanisms that eliminate the 392 need for password authentication. The chief deployment obstacle has 393 been the lack of support infrastructure. Until there is a large 394 population of Web users equipped with the means to use a password 395 alternative, there is no incentive for Web sites to accept 396 alternatives. And until Web sites accept alternatives there is no 397 incentive for users to change their behavior. 399 The mesh provides a mechanism that allows every device a user owns to 400 be provisioned with a public key pair and credential chain. This 401 allows the use of existing protocols such as SAML and OpenID Connect 402 to be used to replace passwords completely. 404 Instead of being asked to provide a username and password on visiting 405 a Web Site, a user would only need to provide authentication when a 406 security critical choice was being made. A user should not need to 407 'log in' to read a newspaper but additional confirmation is certainly 408 required when they decide to make a purchase or transfer funds from 409 their bank. 411 2.3. Encrypted Email 413 Encrypted email was the original purpose for which the mesh 414 technology was developed under the name 'Prism-Proof email'. By 415 default, the mesh prototype will automatically configure certain 416 email clients for the use of encrypted mail. Once a client is 417 enabled, use of encryption is completely seamless and automatic 418 provided that an S/MIME capable email client is used. 420 While the large deployed base of S/MIME capable clients makes support 421 for this encryption format expedient, the mesh is designed to be 422 completely technology neutral. A public application profile for email 423 can specify the public encryption keys to be used and the encryption 424 formats they should be used with. If the user prefers OpenPGP, this 425 can be offered as an alternative. But rather than perpetuating 426 unnecessary format wars, the preferred situation would be for the 427 default to be to support both. 429 When using mesh enabled email security, a user may opt to make end- 430 to-end encryption their preferred option for an account. But doing so 431 will of course render any email messages unreadable on devices that 432 they have not yet connected to their profile. For this reason it is 433 suggested that early adopters of the email encryption capabilities 434 should consider creating a secondary account for their mesh email. 435 For example, alice@example.com might use mesh.alice@example.com to 436 receive encrypted messages. 438 The mesh provides a solution to two of the major challenges of end- 439 to-end encrypted email, distribution of public keys and management of 440 private keys. As described earlier, use of a public profile on the 441 cryptomesh solves the problem of public key distribution and use of 442 private profiles allows any device that has been connected to a 443 profile to access the current decryption key. 445 2.4. WiFi and Networking 447 One of the most tedious chores in administering a home network is 448 configuring devices to connect to one or more WiFi networks. And once 449 a device has been tediously configured, the work is likely to be 450 undone for the most trivial of reasons or for no reason at all. 452 Once a device is connected to a personal profile, it may be 453 authorized to use any WiFi network that is managed under that 454 profile. Alternatively the network owner may authorize a more limited 455 degree of network access. For example, a house guest might be 456 permitted to access a home WiFi network but only for a limited 457 period. 459 2.5. Internet of Things 461 One of the primary motivations for designing the mesh was the 462 realization that with 50 IP addresses already assigned on the home 463 networks and a further 30 non-IP based network devices already 464 deployed, reducing network administration effort has become a 465 necessity, not a luxury. An automated home does not reduce effort or 466 stress if connected devices are perpetually failing or requiring 467 software upgrades. 469 Connecting an Internet of Things device such as a light bulb or a 3D 470 printer is little different in principle to connecting a computer or 471 a phone. The chief difference being that such devices may lack a 472 keyboard or a display of any kind and it may be desirable to limit 473 the degree of network access allowed. The coffee pot does not need to 474 run a file server or send thousands of emails a second, permitting 475 such access increases the risk of the device being compromised, 476 therefore the principle of least privilege demands that such a device 477 not be allowed unrestricted Internet access. 479 2.6. Developer Tools 481 Although the mesh is designed to support the needs of all Web users, 482 it is to be expected that early most adopters will be among the more 483 expert users. 485 The mesh provides a general purpose infrastructure on which any 486 application such as SSH or code signing can connect to cryptographic 487 credentials and resources as required. 489 3. Architecture 491 The foundational principle of the mesh is that the mesh cannot be 492 breached because the mesh does not offer any security guarantees. 494 * The mesh cannot suffer disclosure breach because all 495 confidential data stored in the mesh is encrypted end-to-end 496 using strong cryptographic algorithms and keys. This ensures 497 that the confidentiality of the data is protected unless the 498 encryption algorithms are broken or a breach occurs at the 499 end points where the private keys are stored. 501 * The mesh cannot suffer a permanent denial of service attack 502 as each mesh profile manager maintains a local copy of all 503 data stored in the mesh. Even if a mesh ceases operations 504 completely, a user may provision the same personal 505 profile(s) to a different mesh to quickly re-establish 506 service. 508 * Recognizing the advances in computational power since the 509 original development of PKI in the mid-1990s, cryptographic 510 hygiene is encouraged through use of separate cryptographic 511 key material unless there are practical reasons to avoid 512 this approach. 514 A consequence of the last principle is that a Personal PKI for a user 515 with a large number of devices will have a large number of 516 cryptographic keys. In particular every device has its own keys for 517 authentication and key distribution and key material SHOULD NOT be 518 shared between application profiles. For applications such as email 519 encryption where it is desirable to be able to decrypt messages on 520 any connected device, a single encryption/decryption keypair MAY be 521 provisioned to multiple devices. In such circumstances, it is highly 522 desirable that such keys be rotated on a regular basis and in 523 particular when a device that has been provisioned with a current 524 decryption key is being disconnected from a profile. 526 3.1. Profiles 528 Three types of profile are currently defined: 530 Personal Profile 531 Each mesh user has one or more personal profiles to which 532 they may connect devices and applications as they choose. 534 Device Profile 535 Contains keys and settings for a device. A device profile 536 MAY be connected to multiple Personal Profiles at the same 537 time. 539 Application Profile 540 Contains keys and settings for a set of applications. An 541 application profile can only connect to one personal profile 542 at a time but MAY be transferred from one Personal Profile 543 to a successor. 545 The need for a profile to describe enterprise security configuration 546 data is acknowledged but not currently addressed. 548 3.1.1. Personal Profile 550 A personal profile consists of: 552 * A Personal PKI. [Public] 554 * A set of masked account identifiers. [Public, Signed] 556 * A set of Device Connection Entries. [Private, Signed] 557 * A set of profiles describing applications enabled for that 558 account. [Private, Signed] 560 Items marked [Signed] are signed under a current Administration key 561 and Items marked [Private] are encrypted under the set of current 562 profile administration keys. 564 3.1.1.1. Personal PKI 566 Each Personal Profile contains a personal PKI hierarchy consisting 567 of: 569 Personal Master Signature Key (PMSK) 570 The root of trust for the Personal PKI, the public key of 571 the PMSK is presented as a self-signed X.509v3 certificate 572 with Certificate Signing use enabled. The PMSK is used to 573 sign certificates for the PMEK, POSK and PKEK keys. 575 Personal Master Escrow Key(s) (PMEK) 576 A Personal Profile MAY contain one or more PMEK keys to 577 enable escrow of private keys used for stored data. Note 578 that the presence and use of an escrow key are both 579 optional. A user MAY chose to create a profile without a 580 PMEK or choose not to use the escrow capability of a profile 581 that has a PMEK specified. 583 Personal Online Signature Key (POSK) 584 A Personal profile contains at least one POSK which is used 585 to sign device administration application keys. 587 The private key portions of the PMSK and PMEK are only ever used 588 during the initial configuration of the Personal PKI and in disaster 589 recovery situations. If a user loses access to a decryption key, the 590 PMEK may be used to recover and decrypt an escrowed copy. If a user 591 loses control over their POSK private key due to a device theft or 592 other compromise, the PMSK may be used to revoke it and possibly 593 establish a replacement. 595 Due to the importance of and infrequent need for access to the PMSK 596 and PMEK, profile managers MUST support and SHOULD encourage use of 597 the offline escrow mechanism described below for these private keys. 599 The key fingerprint of the PMSK is used as a unique identifier for 600 the corresponding profile. 602 3.1.1.2. Device Connection Entry 604 A Device Connection Entry contains: 606 * The fingerprint of the Device Master Signature Key to which 607 it applies 609 * A set of application profiles connected to the personal 610 profile that the device is authorized to access 612 3.1.1.3. Application Profile 614 An Application Profile contains credential and network connection 615 data necessary to use a particular type of application such as 616 'email' or the password manager. 618 3.1.2. Device Profile 620 Each device that is connected to one or more Personal Profiles 621 publishes a device profile. A device may be connected to more than 622 one profile simultaneously. In this case the device MAY have separate 623 device profiles for each Personal Profile it is connected to or use a 624 common profile. 626 Device Master Signature Key (DSKK) 627 Used sign certificates for the DAK, DDK and DKEK and device 628 profiles. 630 Device Authentication Key (DAK) 631 Used to authenticate device requests. 633 Device Decryption Key (DDK) 634 Used to decrypt private portions of a device profile for 635 that device. For example, private keys, passwords etc. 637 3.2. Escrow 639 The mesh is a mechanism for managing cryptographic keys. Since the 640 ability to escrow private keys is an important function of a key 641 management infrastructure, the mesh provides an escrow mechanism. The 642 allows the mesh to enable applications involving stored data such as 643 whole disk encryption and end-to-end encrypted email while providing 644 safeguards against the risk of data loss should a device securing a 645 decryption key fail. 647 Although it is in principle possible to escrow any private key, the 648 use of an escrow mechanism dilutes the non-repudiation and forward 649 secrecy assurances that an application might assume. Thus the use of 650 key escrow is typically limited to: 652 * Profile Master Keys (the PMSK and PMEKs) 654 * Decryption Keys used for encrypted stored data 656 A two tier escrow scheme is supported: 658 Online Escrow 659 The private key data is encrypted under a PMEK key described 660 in the Personal Profile. 662 Offline Escrow 663 The private key data is encrypted under a symmetric recovery 664 key. The recovery key is typically split using a key sharing 665 mechanism and the shares stored in a non-volatile media such 666 as ink and paper. 668 Note that in each case, the encrypted private key data is 669 typically stored in the mesh. It is only the means to 670 decrypt the escrow record that is online or offline. 672 3.2.1. Offline Escrow 674 Use of the offline escrow mechanism is typically limited to escrow of 675 the profile master keys (PMSK, PMEK) for which the online escrow 676 mechanism cannot be used. 678 Since the encrypted data will be stored as public data in the mesh, 679 the process used to generate the recovery key MUST ensure that it 680 contains at least as much ergodicity as the private key being 681 protected without disclosing information on the private key itself. 682 One means of ensuring that this is achieved is to generate a random 683 nonce value using the best available source and combine it with the 684 private key being escrowed by means of a secure cryptographic digest. 686 In order to minimize the amount of data required to recover escrowed 687 data, the object identifier of an offline escrow entry is the 688 fingerprint (i.e. a one way secure digest) of the recovery key. 690 Online Escrow 692 In the online escrow mechanism, the private key data is encrypted 693 under the PMEK of the associated profile. 695 The object identifier of an online escrow entry is formed by 696 encrypting the corresponding public key identifier under the PKEK of 697 the associated profile and taking the fingerprint. 699 3.3. Identifiers 701 3.3.1. Object Identifiers 703 Every entry stored in the Mesh has an object identifier. The form of 704 the identifier is a Uniform Data Fingerprint (UDF). The input data 705 and precision are chosen to ensure that the object identifier is 706 globally unique with an acceptably high degree of assurance. 708 For the sake of convenience, the prototype mesh uses identifiers with 709 125 bit precision ensuring a negligible probability of two objects 710 being created with the same identifier until 2^50 (~10^15) entries 711 have been registered. A mesh gateway MAY chose a different level of 712 required precision or increase the level of precision required at any 713 time. 715 3.3.2. Account Identifier 717 An account identifier provides a user-friendly means of identifying a 718 mesh profile. A personal profile MAY have multiple account 719 identifiers but a MESH gateway MUST NOT permit the same account 720 identifier to be used to identify more than one profile at a time. 722 Account identifiers are assigned by a mesh gateway and entered using 723 the same form as an email address (i.e. @) where is the domain name 724 of the mesh gateway that assigned the identifier. This approach 725 avoids the need to ensure that account identifiers are globally 726 unique. To avoid enumeration attacks and similar forms of abuse, only 727 the fingerprint of the account identifier is exposed to the Mesh. 729 For example, Alice registers her personal profile at example.com 730 using the account identifiers 'alice' and 'bob'. This prevents Bob 731 from registering his profile at example.com as 'bob'. Alice then buys 732 a phone, to connect her phone to her Personal Profile, Alice enters 733 'alice@example.com' as her account identifier in the phone profile 734 manager. This allows the phone to retrieve Alice's personal profile 735 from the Mesh and present the fingerprint of the profile to Alice for 736 verification. 738 meshid = accountid ["@" domain] 740 accountid = username | fingerprint 742 3.3.3. Profile Identifier URI 744 The URI form of the profile identifier is a compact, machine 745 independent means of identifying a mesh profile. Since a personal 746 profile provides both a means of specifying an account 747 For example, a server configuration file might grant access to Alice 748 as follows. 750 mmm:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice@cryptomesh.org {RWED} 752 Mesh profiles are identified using the mmm URI scheme as follows: 754 meshuri = "mmm:" fingerprint [ ":" meshid] 756 4. Application Profiles 758 Application profiles store information for use by a particular class 759 of application. A Personal Profile MAY contain more than one 760 application profile of a particular type and a single application 761 profile MAY describe the use of multiple protocols. 763 For example a user with multiple email accounts would require a 764 separate Email Application Profile for each account each of which 765 would typically specify connections for SUBMIT and IMAP/POP services 766 and public and private key sets for S/MIME and OpenPGP. 768 Application profiles are exchanged in JSON format. The schemas for 769 the individual application profiles will be described in a future 770 document. 772 4.1. Administration 774 The administration application profile is used to administer 775 connection of devices to a Personal Profile and enable the use of 776 particular application profiles on particular devices. 778 The public portion of the administration profile is the Personal 779 Profile itself. The private profile contains: 781 * Private Key of the POSK 783 4.2. Escrow 785 The escrow application profile is used to administer escrow of 786 private keys. The escrow profile contains: 788 * Escrow Public Key 790 * Escrow Identifier Encryption Key 792 4.3. Network Connection 794 A network application profile contains information for configuring a 795 network connection. This may include: 797 * Connection data for one or more DNS services 799 * A scope for which the network connection is applied 801 4.4. Password Manager 803 A password manager application profile contains a list of password 804 entries each containing: 806 * The domain(s) for which the entry is to be used [required] 808 * Username [required] 810 * Password [required] 812 * HTTP strict security policy entry for the site [optional] 814 * HTTP Key Pining Security Policy for the site [optional] 816 * Acceptable authentication mechanisms [optional] 818 All the entries in the password manager are private with a decryption 819 blob for the device keys of each authorized device. 821 4.5. Authentication 823 While the password manager application is currently necessary it is 824 intended that this should be a transitional infrastructure rather 825 than a permanent one. 827 * The domain(s) for which the entry is to be used [optional] 829 * HTTP strict security policy entry for the site [optional] 831 * HTTP Key Pining Security Policy for the site [optional] 833 * Acceptable authentication mechanisms [optional] 835 In addition each device connected to an authentication profile has 836 the following device specific attributes: 838 * Authentication credential 840 4.6. Email 842 Under normal circumstances an email application profile enables use 843 of both S/MIME and OpenPGP security formats. 845 * Outbound mail server connection(s) (e.g. SUBMIT) 846 * Inbound mail server connection(s) (e.g. POP3, IMAP4) 848 * Email encryption key (S/MIME) [Public] 850 * Email encryption key (OpenPGP) [Public] 852 * Email decryption key (S/MIME) [Private] 854 * Email decryption key (OpenPGP) [Private] 856 In addition each device connected to an email profile has the 857 following device specific attributes 859 * Email authentication credentials (OpenPGP) 861 * Email authentication credentials (S/MIME) 863 5. Mesh Services 865 The Mesh supports four separate protocols: 867 Mesh Gateway Service [Gateway] 868 Supports operations that create a permanent record in the 869 Gateway log. These include creation, update and management 870 of Profiles. 872 Mesh Gateway Request Service [Gateway] 873 Supports operations that will only create a permanent record 874 in the Gateway log if confirmed by a properly authorized 875 administration device. 877 Mesh Query Service [Gateway,Distribution] 878 Allows retrieval of information stored in the mesh without 879 creating a record in the Gateway log. 881 Mesh Replication Service [Gateway,Distribution] 882 Manages replication of closed Mesh logs between nodes. 884 The distinction between the two gateway services is that actions 885 performed using the Mesh Gateway Service will be eventually 886 replicated to every node in the mesh. The choice of Mesh node to 887 which a request was originally directed makes no difference after the 888 mesh has synchronized. In contrast, actions requested in the Mesh 889 Gateway Request Service are not permanently recorded or synchronized 890 to other nodes. It is therefore essential that all the steps 891 necessary to complete a transaction be directed to the same service. 893 The detailed description of the Mesh protocols will be described 894 separately in a future document. 896 5.1. Mesh Log 898 Each mesh gateway node maintains an independent, append only log. 899 Each log is maintained as an incremental sequence of parts. Each part 900 is terminated by a signed record containing a digest over all the 901 entries in the current log and a chained digest over the digest of 902 the current log and the chained digest of the previous log. 904 Each mesh gateway performs a log rollover operation at frequent 905 intervals. The gateway begins a new log part which becomes the active 906 part in which all new transactions are recorded. The gateway then 907 calculates the terminal record for the previously active part and 908 writes it to the log to complete it. 910 Note that while this approach is simple and efficient for the mesh 911 gateway, it is not optimized for use by readers attempting to quickly 912 verify a single entry in the log. This may be revisited in future 913 versions of the Mesh if warranted. 915 5.2. Mesh Replication 917 At present the Mesh Replication Service has not been implemented. 918 Think NNTP in JSON with transaction records for each gateway node 919 being written to the equivalent of a newsgroup. 921 At present mesh services are presented as JSON services over HTTPS. 923 6. Requirements and Recommendations 925 Since the Mesh MAY be used to store keys for use with the highest 926 security levels supported by standards based cryptography and there 927 is no means of distinguishing high security keys from lesser keys, 928 all cryptographic operations employ the highest security level of the 929 available standards based cryptographic algorithms. This means use of 930 256 bit symmetric keys for encryption and MAC operations and 2048 bit 931 RSA. While longer RSA key sizes are available, the security advantage 932 they offer is not sufficient to justify use. A transition to use of 933 an ECC public key algorithm is preferred. 935 6.1. Requirements 937 A Mesh profile manager MUST support the following algorithms and data 938 formats: 940 * Encryption: AES-256 942 * Digest: SHA-2-512 944 * Public Key Encryption: RSA-2048 945 * Public Key Signature: RSA-2048 947 * Public Key Agreement: DH-2048 949 * PKIX X.509v3 Certificate 951 * JSON (generate, read), JSON-B (read) 953 6.2. Recommendations 955 A Mesh profile manager SHOULD support the following algorithms and 956 data formats: 958 * Encryption: None 960 * Digest: SHA-3-512 [Once published by NIST] 962 * Public Key Encryption: CFRG-448 [When published] 964 * Public Key Signature: CFRG-448 [When published] 966 * JSON-B 968 7. Security Considerations 970 Currently the architecture of the Mesh is in a state of rapid change. 971 Users SHOULD not therefore rely on the security considerations set 972 out in this document without first checking to see if the instance of 973 the mesh they are connecting to follows the version of the mesh 974 protocols to which they refer. 976 7.1. Mesh Integrity 978 The state of the mesh is fully contained in the append-only logs 979 maintained by each mesh gateway. The mesh management protocols 980 require that each gateway sign their append-only log at regular 981 intervals and validate all data provided by other gateway nodes in 982 the mesh. Thus a mesh gateway node is the only party that can perform 983 a record insertion attack that another mesh node can be induced to 984 accept. 986 Further, the management of the logs provides complete transparency 987 for addition of entries by the gateway with continuous auditing by 988 every other mesh gateway. Thus it is impossible for one mesh gateway 989 node to defect unless every other gateway node in the mesh is willing 990 to collude in the deception. 992 7.2. Mesh Data Confidentiality 994 The Mesh does not provide any confidentiality guarantees as all data 995 stored in the mesh is considered to be public. Thus the mesh cannot 996 be breached by definition but private data may be breached through 997 disclosure of the decryption keys or by use of faulty encryption 998 algorithm. 1000 7.3. Disclosure of Private Key 1002 Disclosure of the private keys used to secure private data may result 1003 in disclosure of confidential data. Unencrypted private keys are only 1004 kept at end point devices. Private key disclosure is bad, avoid. 1006 Trustworthy computing features preventing/making it difficult to 1007 extract keys from a device are highly desirable. 1009 7.4. Denial of Service 1011 Denial of Service attacks are an important threat that is not 1012 currently addressed in the prototype implementation. 1014 The use of a combination of proof of work and lightweight 1015 authentication approaches is anticipated to address this 1016 consideration. 1018 7.5. Traffic Analysis 1020 Mesh transactions SHOULD be considered to be vulnerable to traffic 1021 analysis unless a security analysis of a specific mesh instance has 1022 been performed to provide evidence to the contrary. 1024 7.6. Covert Channels 1026 The mesh provides a medium for exchange of end-to-end encrypted data. 1027 Since the mesh nodes have no means of determining the contents of 1028 profile entries, there is no means of restricting use to those 1029 approved by the operators. The mesh thus represents a ubiquitous and 1030 pervasive covert channel. 1032 While this situation is not necessarily to be considered a security 1033 concern for mesh operators, the resources consumed by such operations 1034 may be a concern. Since all profiles entered into the mesh are 1035 permanently recorded and replicated to every mesh node, use of the 1036 mesh for purposes such as covert transfer of streaming video are 1037 likely to be a concern. 1039 The use of resource limiting strategies such as CAPTCHAs, profile 1040 size limits and limits on the number of updates individual users are 1041 permitted to make in a short time period SHOULD therefore be 1042 considered. 1044 7.7. Data Loss 1046 The risk of data loss is mitigated through a combination of local 1047 retention, use of the mesh to provide data persistence and key 1048 escrow. 1050 7.8. User Capture 1052 User capture is the situation where a user of a software service is 1053 unable to change software service providers due to unacceptably high 1054 switching costs. This puts the user of the service at a severe 1055 disadvantage to the provider. While achieving such a circumstance is 1056 frequently the objective of many a business plan, such plans almost 1057 invariably fail. 1059 Local capture of Mesh data and the planned mesh replication 1060 infrastructure ensure that switching costs for users are never 1061 prohibitive. Thus user capture is avoided. 1063 8. IANA Requirements 1065 8.1. Registration of mmm URI Scheme (provisional) 1067 TBS 1069 8.2. Registration of application/mesh Content Types 1071 TBS 1073 9. Acknowledgements 1075 The mesh builds on much prior art in the field. 1077 As described above, the mesh deployment model consciously follows the 1078 pattern set by the World Wide Web which was in turn based on 1079 observation of the success of earlier innovations such as the micro- 1080 computer. The purpose for which the Web was designed was to make the 1081 universe of information accessible, the killer application for the 1082 Web at CERN was the ability to access the telephone directory online. 1084 The use of append-only logs with chained cryptographic digests was 1085 originally proposed by Harber and Stornetta but only popularized 1086 through the use in the BitCoin blockchain and the Certificate 1087 Transparency log after the patent protection expired. 1089 The idea of using X.509 to establish a personal PKI hierarchy arose 1090 from discussions with Sir Tim Berners-Lee at CERN in 1994. The use of 1091 fingerprints of public keys was introduced by Phil Zimmerman in PGP. 1093 Author's Address 1095 Phillip Hallam-Baker 1096 Comodo Group Inc. 1098 philliph@comodo.com