idnits 2.17.1 draft-hallambaker-mesh-naming-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 631: '... MUA is SIN-Aware, it MUST resolve the...' RFC 2119 keyword, line 635: '... the MUA is SIN-Aware, it MUST resolve...' RFC 2119 keyword, line 685: '... TLS certificate MUST validate if it i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2017) is 2449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3709 (Obsoleted by RFC 9399) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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 August 12, 2017 5 Expires: February 13, 2018 7 Naming in the Mathematical Mesh. 8 draft-hallambaker-mesh-naming-00 10 Abstract 12 The importance of naming in information systems is explained with 13 reference to a typical use case. Existing Internet naming systems 14 attempt to strike a balance between usability and machine 15 readability. An alternative approach in which separate classes of 16 identifiers are introduced for human and machine interaction is 17 described. Human Interaction Identifiers are interpreted in the 18 context in which they are used and are thus more compact and offer a 19 superior user experience. Strong Internet Names are a form of 20 Machine Interaction Identifier that are backwards compatible with 21 existing Internet names that include a DNS address and are 22 cryptographically bound to a security policy governing 23 interpretation. The application of these approaches in the 24 Mathematical Mesh is described. 26 This document is also available online at 27 http://prismproof.org/Documents/draft-hallambaker-mesh-naming.html . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 13, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Identifiers and Naming . . . . . . . . . . . . . . . . . 4 65 2. Identifiers in the Mathematical Mesh. . . . . . . . . . . . . 6 66 2.1. Human Interaction Identifiers . . . . . . . . . . . . . . 7 67 2.1.1. User Expectation . . . . . . . . . . . . . . . . . . 8 68 2.2. Machine Interaction Identifiers . . . . . . . . . . . . . 9 69 2.3. Mapping Human Interaction to Machine . . . . . . . . . . 10 70 3. Strong Internet Names . . . . . . . . . . . . . . . . . . . . 12 71 3.1. UDF Fingerprint . . . . . . . . . . . . . . . . . . . . . 12 72 3.2. Strong Email Addresses . . . . . . . . . . . . . . . . . 13 73 3.3. Network Administration . . . . . . . . . . . . . . . . . 14 74 3.4. Security Policy Specification . . . . . . . . . . . . . . 16 75 3.5. Resolving SINs . . . . . . . . . . . . . . . . . . . . . 17 76 4. Personal Mesh . . . . . . . . . . . . . . . . . . . . . . . . 18 77 4.1. Connecting Devices . . . . . . . . . . . . . . . . . . . 19 78 4.2. Connecting Applications . . . . . . . . . . . . . . . . . 20 79 4.3. Contacts Directory . . . . . . . . . . . . . . . . . . . 20 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 6.1. Expectations . . . . . . . . . . . . . . . . . . . . . . 21 83 6.2. Work Factor . . . . . . . . . . . . . . . . . . . . . . . 21 84 6.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 21 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 8. Informative References . . . . . . . . . . . . . . . . . . . 22 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Use Case 91 Hollywood Alice arrives at the airport. Her hire car is already 92 waiting for her at the curb, every aspect of its function precisely 93 matched to her preferences. The radio is tuned to her favorite 94 station, the seats, mirrors and driving controls adapt to her 95 measurements and of course, the navigation system is already 96 programed with her itinerary. 98 On the way to her destination, Hollywood Alice places a conference 99 call to Bob and Carol by speaking their name. Bob wants to know if 100 Alice?s new camera arrived in time for her trip. It did, but only 101 just. Alice had only a few minutes to unwrap it and pack it for her 102 trip. Carol has been to the area before and tells Alice she must see 103 the Golden Gate bridge from Baker Beach, the same spot that Ansel 104 Adams took his famous landscapes before and after the bridge was 105 built. The navigator updates its route accordingly and Alice arrives 106 in the golden hour. 108 Her camera is a large modern DSLR but it doesn?t have a GPS, it 109 doesn?t need one as it automatically captures this data from her 110 mobile phone via Bluetooth. Alice joins the camera to the conference 111 and it uses the same connection to upload thumbnails of her pictures 112 for Bob and Carol. When she gets to her hotel room, the camera will 113 upload the raw files to Alice?s personal cloud using the high-speed 114 connection. 116 It all works so much better in Hollywood. 118 An extremely wealthy real-world Alice being followed by a minibus 119 containing a road crew of a half dozen IT support staff might 120 possibly be able to create a similar user experience today but even 121 that is doubtful. Instead of taking pictures of the Golden Gate 122 bridge at sunset, Real-world Alice is far more likely to find herself 123 at the side of the road debugging Perl scripts or more likely, 124 turning all the ?labor-saving? technology off because it simply isn?t 125 worth the hassle. We have all the parts but they just don?t fit 126 together properly and even when they appear to be joined, they often 127 come apart. A ?seamless user experience? that isn?t actually 128 seamless makes things worse, not better. 130 There are many reasons that the scenario described above remains a 131 pipe dream, not least the commercial interests of the technology 132 providers. But one of the biggest obstacles to providing the 133 seamless integration experienced by Hollywood Alice is the lack of a 134 secure naming infrastructure. Providing Alice with a seamless user 135 experience required seven data exchanges and ten trust relationships. 137 [[This figure is not viewable in this format. The figure is 138 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 139 naming.html.]] 141 Information flows in the Hollywood Alice scenario. 143 The only infrastructures currently capable of managing those trust 144 relationships would require Alice to be in constant communication 145 with some form of ?identity provider? and to surrender a large part 146 of her personal control to that infrastructure. 148 There are proprietary infrastructures that provide an approximation 149 of the user experience if Alice buys all her devices from the same 150 vendor. But these require Alice to surrender even more personal 151 control and in any case, there is no single company that makes 152 phones, DSLR cameras and rents cars. And even if such a company 153 existed, Alice would not be able to achieve seamless connectivity to 154 Bob and Carol unless they live in the same walled garden as Alice. 156 This document explores the problem of secure naming and describes the 157 approach to naming taken in the Mathematical Mesh, a Personal Public 158 Key Infrastructure (PPKI) that is designed to make computers easier 159 to use by making them more secure. 161 The central idea is this: Current Internet identifiers are designed 162 to provide a balance between human and machine use. Separating the 163 functions allows a vastly more satisfactory user experience, in most 164 cases the name of the intended referent being implicit from the 165 context in which it is used. The key to making this approach 166 practical being the introduction of a new form of very explicit 167 identifier which is cryptographically bound to the context in which 168 it is interpreted but is nevertheless backwards compatible with 169 existing Internet identifiers through the use of DNS prefixing. 171 1.1. Identifiers and Naming 173 In the field of semiotics, a name is a symbol whose meaning is purely 174 conventional, that is the meaning of the name is based on nothing 175 more than a common agreement to interpret it in a specific way. Most 176 network identifiers are based on a name of some sort whether they be 177 example.com or 127.0.0.1. The proper functioning of the Internet 178 depends on all the participants agreeing on a common interpretation 179 of these identifiers which in turn gives rise for the need for naming 180 authorities. 182 Since a name is merely the result of an agreement, any naming scheme 183 must be governed by an authority, even if that authority is just the 184 one person who uses the names. The question of authority is thus an 185 inescapable one when considering the security properties of naming 186 schemes. 188 One of the core technologies that made the World Wide Web possible 189 was the realization that the means to resolve any network resource 190 may be specified by means of a triple, {what, where, how}. The 191 Uniform Resource Locator (URL) [RFC3986] [RFC3986] is simply a syntax 192 for expressing this triple in a single identifier: how://where/what. 193 It seems intuitively obvious that whether these are expressed as one 194 single unit or three ?should? make no difference. But the lightning 195 success of the World Wide Web proves that combining all the 196 information necessary into a single identifier makes all the 197 difference in the world. 199 While a URL contains a name component, it is not a pure name: The 200 interpretation of the where component is intersubjectively determined 201 by the choice of ICANN as the ultimate DNS naming authority, the 202 interpretation of what and how is determined by the protocol 203 specifications. Different users attempting to resolve 204 http://example.com/ in different parts of the world may not receive 205 back the same exact sequence of bytes but provided they are connected 206 to ?the Internet? they should receive back a representation of the 207 same ?network resource?. 209 Interpretation of the other type of Internet identifier users 210 commonly encounter, the email address, is not so straightforward. 211 Unlike a URL, the RFC822 email address does not contain a how 212 component. It is implicit that alice@example.com is an SMTP email 213 address, but this is only one of many ways in which it may be used 214 today: 216 o Send SMTP email 218 o Initiate an XMPP chat 220 o Web site username 222 o Initiate a proprietary chat 224 o Comment on a Web forum 226 From the user?s perspective, it is natural to assume that the address 227 alice@example.com is held by the same individual in each of these 228 contexts. But like many aspects of the Internet today, it is a 229 mistaken assumption. The holder of the email address may or may not 230 be the same as the person who responds when a chat session is 231 initiated. 233 An RFC822 email address is a combination of two names issued by 234 separate authorities who@where. Since the where component is a DNS 235 name, there is a certain degree of consistency in interpretation 236 through the infrastructure managed by ICANN. No such guarantees are 237 provided for the interpretation of who. A site may have a policy 238 preventing reissue of account names to new users or it may not. 240 The use of email addresses as identifiers on third party sites 241 introduces a third authority. For example, Alice may use her email 242 address alice@example.com as her account identifier for the chat 243 service provided by example.net. Resolution of the name example.com 244 is now controlled by the unseen third authority example.net but only 245 within the context of the example.net chat application. 247 While these concerns may appear abstract, the security consequences 248 are anything but. It is the fact that alice@example.com could be the 249 same person or different people that makes the Hollywood Alice 250 experience unreachable today. Alice?s phone can?t integrate with her 251 hire car or her camera or her cloud communications provider because 252 they lack a common language for securely identifying themselves as 253 belonging to Alice. 255 The identifiers we use in the Internet today represent a compromise 256 between expressiveness and usability. The more information we 257 attempt to pack into an identifier, the more a user must remember or 258 type or read. If we are to introduce a cryptographically secure 259 identifier it must therefore be a subclass of identifier, an 260 identifier which is usually if not always hidden ?under the covers? 261 and is separate from the names that the user sees and interacts with. 262 This is the purpose that the Mathematical Mesh PPKI serves. 264 2. Identifiers in the Mathematical Mesh. 266 The Mathematical Mesh [draft-hallambaker-mesh-architecture] 267 [draft-hallambaker-mesh-architecture] is a PPKI that manages two 268 types of identifies: Human-Interaction identifiers which are 269 primarily designed to support human interaction and Machine- 270 Interaction identifiers which are primarily designed to support 271 interactions between machines. 273 As we saw in the previous section, these categories are not 274 necessarily exclusive. Most of Internet names used on the Internet 275 today were designed to provide a compromise between human and machine 276 interactions. Such a compromise is not practical in a cryptographic 277 infrastructure such as the Mesh since there is really no way to make 278 an identifier that presents a cryptographic work factor of 2118 or 279 better human friendly except by mapping it to another identifier 280 designed for human use. 282 This section first describes the two types of identifier used in the 283 Mesh and how one may be mapped to the other. The following sections 284 describe the implementation of these ideas in the current 285 implementation of the Mesh. 287 2.1. Human Interaction Identifiers 289 Human Interaction identifiers come in many different forms and a 290 given user may use multiple identifiers to refer to the same entity 291 in different contexts. Three different uses are distinguished: 293 An identifier that the human user uses when entering a command. 294 (e.g. ?conference Bob and Carol?) 296 An identifier that is presented to the human user when requesting 297 user interaction. (e.g. ?Alice Cryptographer is calling?) 299 An output identifier that is used only to determine if two things 300 are the same. Comparison identifiers are used in the Mesh when 301 connecting a device to a profile. 303 Depending on the circumstances in which the identifiers are used, it 304 is generally desirable that input identifiers be as compact as 305 possible while output identifiers may provide more information. If 306 Bob receives the conference request from Carol on his smartphone it 307 is probably desirable for the display to present both the shortcut 308 identifier from his personal contact directory ?Alice? and her full 309 personal name ?Alice Cryptographer?. 311 While most identifier forms used for input (text, voice) may also be 312 used for output, the reverse is not true. A validated image of a 313 subject?s trademark, as supported by the PKIX logotype extension 314 [RFC3709] [RFC3709] provides a powerful means of telling a user which 315 party operates the site they are visiting but would be highly 316 impractical as an input format. 318 The Mathematical Mesh makes use of three different types of human- 319 interaction identifier: 321 An identifier that is intended to be globally unambiguous. (e.g. 322 alice@example.com) 324 An identifier that is only unambiguous within a specific context 325 (e.g. ?conference Bob and Carol?) 327 An identifier whose referent is defined by the context in which it 328 is used (e.g. ?localhost?) 330 For most human interactions, it is desirable to use the shortest 331 identifier possible for input that does not lead to ambiguity. Thus, 332 the use of contextual identifiers is generally preferred over global 333 identifiers and the use of implicit identifiers is almost always 334 best. 336 Most of the identifiers used in the ?Hollywood Alice? scenario were 337 implicit identifiers. The devices Alice used understood the target 338 of the commands she gave by the context in which she used them. As 339 will be seen, the introduction of Strong Internet Names at the 340 machine level allows them to be eliminated at the human level. 342 The only contextual identifiers that Alice used were ?Bob? and 343 ?Carol? which were names from Alice?s personal contacts directory. 344 There are many Bobs in the world but only one ?Bob? in Alice?s 345 contact book. 347 The Hollywood Alice scenario only involved three people and a set of 348 devices owned or rented by Alice. There was no need for global 349 identifiers because the scenario did not require Alice to interact 350 with the wider world. But it is the ability to communicate and 351 interact on a global scale that gives the Internet its full power. 352 It is the ability to establish secure communication with practically 353 anyone in the world that makes the Internet the primary engine of 354 international commerce. It is also the capability that gives rise to 355 most Internet security concerns. 357 2.1.1. User Expectation 359 One of the chief differences between human interaction identifiers 360 and machine interaction identifiers is that humans interact with 361 certain expectations that may or may not be met. It is the 362 manipulation of the user?s expectations that enables many types of 363 phishing fraud. 365 If a user sees a message that appears to come from a financial 366 institution that they have a business relationship with and that 367 expectation is not met, the result is likely to be some form of fraud 368 on the user. Such failures are always and only the fault of the 369 designers of the communications infrastructure. The user is never 370 negligent, the user is never at fault if their action is the result 371 of a good faith expectation of a different result. 373 When the Internet was new, it was often viewed as creating a reality 374 that was distinct and different from the ?real? offline world. While 375 this point of view is still a common position among Internet protocol 376 designers, it is no longer the case for an increasing proportion of 377 users. The Internet existed before they did, they have been using 378 the Internet since before they could talk. For the Internet 379 generation, there is no online world, only the world. 381 It is the fact that human interaction identifiers are bound to 382 expectations that give rise to security concerns in defining the 383 mapping from human interaction identifiers to machine. If we are to 384 avoid the need to deal with expectations in the interpretation of 385 Machine Interaction Identifiers, we must use cryptography. 387 2.2. Machine Interaction Identifiers 389 Traditional Internet names are designed to achieve a balance between 390 human and machine interaction. As a result, these identifiers omit 391 much of the context that we require at the machine level to avoid the 392 need to address the issue of expectations. 394 For example, the identifier https://example.com/ specifies a resource 395 that is to be retrieved by means of a TLS secured conversation but 396 not the trust context in which the communication is to be 397 established. While this is an acceptable, and in many cases an 398 unavoidable situation for a human interaction identifier, it is a 399 circumstance that is often unacceptable in the Internet of Things. 401 Take for example, a high-risk process control application such as the 402 placement of control rods in a nuclear reactor. A control loop 403 critical to plant safety is governed by means of a three-term (PID) 404 controller connected to a temperature sensor, an actuator and the 405 Supervisory Control and Data Acquisition (SCADA) system. We would 406 wish for it to be possible for all these communications to be secured 407 cryptographically but we are required by regulation to account for 408 the correct operation of any infrastructure on which we rely. The 409 introduction of any Trusted Third Party role whether that be a WebPKI 410 CA or a ICANN managing the DNSSEC, is going to be unacceptable. 412 The Mathematical Mesh introduces a new form of name, the Strong 413 Internet Name (SIN). A SIN is a name that is cryptographically bound 414 to a security policy government the interpretation of the name. The 415 use of a SIN is thus bound to a specific trust context. 417 The use of SINs in Mesh enabled applications closely resembles the 418 use of DNS names and IP addresses at the network level. In normal 419 circumstances, the user only interacts with DNS names which are a 420 name designed for human interaction. But the Internet core has no 421 understanding or knowledge of DNS names. The only identifiers 422 understood at the narrow waist are IP Addresses and so we must 423 translate the DNS names to IP addresses to establish Internet 424 communications. 426 2.3. Mapping Human Interaction to Machine 428 To make use of a Human Interaction Identifier, it must be first 429 mapped to Machine Interaction identifier. We consider this mapping 430 to be secure if and only if this translation meets the good-faith 431 expectations of the user. If a user encounters a Human Interaction 432 identifier that leads the user to reasonably expect that they will be 433 interacting with their bank, this expectation must be met or a 434 serious security vulnerability is created. 436 The terms ?reasonable expectation? and ?good-faith? are of course 437 subjective but not entirely without meaning. The various financial 438 institutions that support the use of non-cash payments in the US 439 operate under rules that absolve the user from blame or loss in 440 almost any circumstance but nevertheless manage to profitably 441 transfer an average of over $500 billion every day [FedRes2016] 442 [FedRes2016] . 444 The Mesh does not impose a model for mapping human to machine 445 interaction identifiers but it does allow the user to put that 446 mapping under their personal control. Devices connected to a Mesh 447 Personal Profile share the same view of the world; the same set of 448 bookmarks and contacts for defining personal names and the same set 449 of trust roots for Certification Authorities trusted to provide 450 brokered trust. 452 In the existing model, mapping of the address https://example.com/ to 453 a secure TLS endpoint takes place in two stages. First the DNS 454 infrastructure is used to resolve the address example.com to an IP 455 address. Next, the client begins making a connection to the host at 456 the specified IP address, receives and validates a PKIX trust chain 457 to a recognized authority and if satisfactory, declares the TLS 458 connection trusted: 460 [[This figure is not viewable in this format. The figure is 461 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 462 naming.html.]] 464 Traditional Internet discovery 466 This approach is serviceable for the intended purpose of the WebPKI: 467 Authenticating the Web sites that the user interacts with. It is 468 less satisfactory as the basis for establishing connections in the 469 Hollywood Alice scenario. 471 One of the biggest problems with the traditional approach is that TLS 472 is only used to authenticate the server to the client. The user 473 experience for client certificates remains unacceptable leaving 474 usernames and passwords as the only available credentialing 475 mechanism. 477 Consider the role of the camera in the Hollywood Alice scenario. 478 Alice uses the camera to take pictures but this is only one of four 479 interactions involving the camera. If we are to achieve the 480 Hollywood Alice user experience, these other three interactions must 481 take place without any intervention by Alice. But this is impossible 482 if Alice is required to constantly enter passwords. 484 [[This figure is not viewable in this format. The figure is 485 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 486 naming.html.]] 488 Information flows involving Alice's DLSR 490 Another limitation of this approach is that the naming role of the 491 Certificate Authority is limited to validating DNS names. This is a 492 major constraint if our goal is moving beyond use of DNS for naming. 494 To achieve a satisfactory user experience, we need to reverse the 495 order of operations. We make use of trusted authorities when mapping 496 the human interaction identifier to a machine interaction identifier 497 whose interpretation does not depend on a trusted authority. 499 [[This figure is not viewable in this format. The figure is 500 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 501 naming.html.]] 503 Use as Trusted Authorities as Introducers. 505 The most important trusted authority for Alice is of course, Alice 506 herself. While a typical Web user may visit hundreds or even 507 thousands of different Web sites in a month, they will only buy from 508 a rather smaller number and will in most cases use one or two 509 financial institutions. 511 When Alice opens an account with a new financial institution, she 512 adds them to her personal contact directory and (optionally) gives 513 them a shortcut name. In the process, she reviews the credentials 514 presented by the bank, a WebPKI Extended Validation certificate with 515 a logotype extension presenting the Bank trademark. From the point 516 at which the financial institution is added to Alice?s personal 517 contact directory, the role of the Trust Authority is limited to 518 revoking the trust relationship should the need arise. 520 If this approach is to work, we need a new type of Machine 521 Interpretation Identifier, one that can express both the network 522 addressing and the trust relationship to the network endpoint. 523 Strong Internet Names are one possible approach towards that goal. 525 3. Strong Internet Names 527 A Strong Internet Name (SIN) is a name containing a DNS label that is 528 cryptographically bound to a security policy government the 529 interpretation of the name. 531 The use of fingerprints of cryptographic keys to establish was 532 introduced in PGP. PGP fingerprints provide a secure means of 533 authenticating the public key(s) of an email user but at the cost of 534 introducing a second identifier for each user that senders must 535 manage in addition to their email address. Like many issues in 536 computing, this is a simple matter until faced with application 537 software that does not support it. 539 Use of a SIN DNS label permits these two pieces of information to be 540 combined in a single identifier that is compliant with existing 541 application software by employing the DNS prefix approach introduced 542 by punycode [RFC3492] [RFC3492] . It is established that DNS names of 543 the form xx-- (where x is any alphabetic character) are 544 reserved. A SIN DNS label has the form mm-- where 545 is the Uniform Data Fingerprint (UDF) of the 546 controlling security policy as described in the following section. 548 3.1. UDF Fingerprint 550 The Uniform Data Fingerprint (UDF) format [draft-hallambaker-udf] 551 [draft-hallambaker-udf] was designed to provide common format for 552 representing fingerprints of data objects formed using a 553 cryptographic digest function such as SHA-2 that was easier on the 554 eye than existing URI schemes such as ni [RFC6920] [RFC6920] . A UDF 555 fingerprint is formed using Base32 with optional digit separators to 556 improve readability. The following is an example of a UDF: 558 MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J 560 Figure 1 562 Unlike traditional fingerprints calculated from the digest of the 563 data itself, a UDF is a strong function of both the referenced data 564 and the IANA content type. 566 Fingerprint = + H ( + ':' + H(<)) 568 Figure 2 570 This approach provides semantic separation between domains. This is 571 necessary to defeat substitution attacks such as presenting an 572 artfully constructed PKIX certificate in a context where a JSON data 573 structure is expected. 575 The Version-ID parameter specifies both the digest function and the 576 method of application. Version-IDs are currently defined for SHA- 577 2-512 and SHA-3-512. The values of these code points have been 578 intentionally chosen to cause the first digit to be either an M 579 (Merkle-Damgard) or an S (Sponge). 581 The specification allows for fingerprint compression in the case that 582 the leading 25, 40, 50 or 55 bits are all zero. This allows a 583 fingerprint of a public key represented in 20 characters (120 bits) 584 to present the same work factor to the attacker as a 25 character 585 fingerprint but at the cost of accepting a 225 increase in key 586 generation difficulty. 588 3.2. Strong Email Addresses 590 A Strong Email Address is an RFC822 compliant email address in which 591 the DNS address part is a SIN bound to a security policy that is 592 relevant to email. For example: 594 An S/MIME certificate to be used for encryption and/or signature 595 as specified by the certificate keyUsage extensions. 597 A root or intermediary certificate under which end user S/MIME 598 certificates must be validated. 600 A comprehensive security policy description language that allows 601 the user to specify the use of S/MIME and OpenPGP keys for 602 encryption and signature and the context in which they are to be 603 used. An example of a possible messaging security policy is 604 described below. 606 For example, Example Inc. holds the domain name example.com and has 607 deployed a private CA whose root of trust is a PKIX certificate with 608 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 610 Alice is an employee of Example Inc., she uses three email addresses: 612 A regular email address (not a SIN). 614 A strong email address that is backwards compatible. 616 A strong email address that is backwards incompatible. 618 All three forms of the address are valid RFC822 addresses and may be 619 used in a legacy email client, stored in an address book application, 620 etc. But the ability of a legacy client to make use of the address 621 differs. Addresses of the first type may always be used. Addresses 622 of the second type may only be used if an appropriate MX record is 623 provisioned. Addresses of the third type will always fail unless the 624 resolver understands that it is a SIN requiring special processing. 626 When specified as the destination address in a Mail User Application 627 (MUA), these addresses have the following interpretations: 629 Send mail to Alice without requiring security enhancements. 631 Send mail to Alice. If the MUA is SIN-Aware, it MUST resolve the 632 security policy specified by the fingerprint and apply security 633 enhancements as mandated by that policy. 635 Only send mail to Alice if the MUA is SIN-Aware, it MUST resolve 636 the security policy specified by the fingerprint and apply 637 security enhancements as mandated by that policy. 639 These rules allow Bob to send email to Alice with either ?best 640 effort? security or mandatory security as the circumstances demand. 642 3.3. Network Administration 644 Strong names may also be used for network configuration. Example 645 Inc. might enable users to force users to make use of a SIN-aware 646 email client by configuring the SRV records for the inbound and 647 outbound mail servers as follows: 649 $origin example.com. 650 _imap._tcp SRV 0 1 995 \ 651 imap.example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz. 652 _submit._tcp SRV 0 1 465 \ 653 smtp.example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz. 655 Figure 3 657 Since the fingerprint mb2gk- is of a PKIX certificate signing 658 certificate, the requirement to use TLS is explicit. This could be 659 specified explicitly by means of a prefixed TXT record as described 660 in [RFC6763] [RFC6763] . 662 For example, Alice is a user of the EXAMPLE service, a version 663 management system used at Example Inc. This is a Web Service 664 described by an SRV record as follows: 666 $origin example.com 667 _example._tcp TXT \ 668 "tls=mb2gk-6duf5-ygyyl-jny5e-rwshz;min=1.2;max=1.3" 669 _example._tcp SRV 0 1 443 host1.example.com 670 _example._tcp SRV 0 1 443 host2.example.com 671 _example._tcp.host1 TXT \ 672 "quic=mm--mb2gk-6duf5-ygyyl-jny5e-rwshz v=2.3" 674 Figure 4 676 Since the UDF fingerprint is used here as a parameter rather than as 677 an embedded part of a DNS name, the mm-- prefix is unnecessary and 678 can be omitted. Though it is probably good manners for applications 679 to tolerate its occurrence in cases where it is unnecessary such as 680 the second TXT record. 682 In this example, there are two separate TXT records describing the 683 EXAMPLE service. The first record applies to all hosts that provide 684 the EXAMPLE service and specifies a PKIX intermediary certificate 685 under which the TLS certificate MUST validate if it is to be 686 accepted. The second TXT record applies only to host1 and contains 687 additional information specific to that host. In this case host1 688 offers the quic protocol but host2 does not. 690 It will be noted that this capability allows similar capabilities to 691 the security policy capabilities provided by TLSA records [RFC6698] 692 [RFC6698] , but in a form that is directly integrated into SRV 693 discovery and offers greater flexibility. A Security Policy 694 specified in a TXT record is not limited to the TLS protocol or even 695 to TLS based key exchanges. The discovery mechanism described in 696 [RFC6763] [RFC6763] has proven utility and is widely used. It is 697 surely time to recognize this fact and back the winner rather than 698 continuing to ignore it for the sake of a favored son. 700 The previous examples demonstrated the use of SINs to perform high 701 level, site wide administration tasks. But the security policy 702 specified in a SIN need not be limited to defining a site wide global 703 root of trust. The following configuration file is used in a 704 robotics project to authenticate command signals between the central 705 controller and various control outputs: 707 Plunger: mm--maxxc-2lxmf-2xs4t-foq5w-63djo.local 708 Exterminator: mm--mcf3x-kzlsh-n2g6z-3iof3-tw43m.local 709 Dome: mm--mdn5z-gkz3i-hnqwy-23tnn-sgqzz.local 710 Lights : mm--ma3nn-wgc43-i3mnn-qwq43-enm5w.local 712 Figure 5 714 Specifying the computer systems controlling the appendages connected 715 to the robot in this way permits all communications to be protected 716 using strong encryption while ensuring that the system can continue 717 to function even if it is impossible to validate the trust paths with 718 respect to an external root of trust. 720 3.4. Security Policy Specification 722 The UDF format used to construct SINs is calculated over both the 723 content data and the IANA content type. This allows the use of SINs 724 to bind an identify to a security policy described in any language 725 whether currently existing or to be defined in the future. A 726 security policy specification may be explicit or implicit. 728 If a security policy is a PKIX Certificate Signing Certificate or 729 End-Entity Certificate, the use of a security protocol consistent 730 with the certificate attributes and protocol is required. This 731 approach allows the use of SINs to require the use of an appropriate 732 security protocol with specified credentials in a wide variety of 733 legacy application protocols. 735 Implicit security policy is convenient but blunt tool. We can 736 establish a baseline for security in the case that an email address 737 SIN authenticates a PKIX end-entity certificate with the 738 dataEncipherment key usage set (i.e. use of S/MIME encryption is 739 required). But once that baseline security is defined, we can only 740 improve on it by decorating the certificate with additional 741 extensions to specify security policy. This approach is unlikely to 742 be satisfactory in the long term. 744 The introduction of an expressive security policy language defined in 745 an appropriate encoding (e.g. YAML, JSON, XML) offers much more 746 interesting possibilities. For example, we would like an enterprise 747 level security policy to allow specification of security policy 748 parameters such as: 750 o The default DNS zone 752 o The UDF of the DNSSEC zone signing key 754 o The UDF of the PKIX enterprise CA 755 o The network directory protocols supported (e.g. LDAP) 757 o The authentication requirements for external network access 759 o IPSEC profile 761 At the user level, a security policy would describe the communication 762 identifiers and protocols by which the person could be contacted. It 763 is quite likely that these would be different depending on who is 764 trying to contact them. End-to-end encryption is not an unqualified 765 benefit when it provides an attacker with a channel for bypassing 766 filtering for spam and malware. Thus, a user level security policy 767 is likely to require conditional clauses: 769 Must sign their email messages with public key enrolled in a Mesh 770 notary log 772 You may send me encrypted messages of any type, including 773 executable code 775 You may send me encrypted messages but not executable code 777 You may send me an encrypted contact request message containing no 778 more than 4K of text characters 780 Here is the public key of my spam filter. 782 While such rules are complex, it is complexity that a user would only 783 ever encounter if they were trying to send a message that violated 784 the rules. 786 As with any configuration language, the specification of a security 787 policy language requires a balance to be struck between simplicity 788 and expressiveness. Discovering the optimal balance is a task left 789 to future work. 791 3.5. Resolving SINs 793 A SIN provides a mechanism for binding an Internet address to a means 794 of authenticating a security policy under which the name is to be 795 interpreted but does not necessarily provide a means for discovering 796 security policies. 798 This omission is intentional as there are many circumstances in which 799 we would want authorized parties to apply a security policy without 800 disclosing the security policy to unauthorized parties. A security 801 policy must inevitably disclose information that might interest an 802 attacker and so it is information that we should not disclose to 803 parties without a need to know. 805 When a synchronous protocol such as VOIP or chat is used, the 806 security policy governing a SIN may be disclosed in-band during the 807 protocol exchange in which the underlying DNS name is used. This 808 approach does not work as well for asynchronous protocols such as 809 email or for network administration. 811 The Mathematical Mesh provides one possible infrastructure that might 812 be used to resolve SINs to the corresponding security policy, and 813 using a linked notary log approach (aka Blockchain), a mechanism for 814 publishing updates securely. It is not the only infrastructure that 815 might be used, nor is it likely to be the best for every application. 816 For example, a new machine connecting to an enterprise network for 817 the first time might obtain its initial security policy through a DNS 818 CERT record [RFC4398] [RFC4398] . 820 4. Personal Mesh 822 To complete the explanation of how to realize the Hollywood Alice 823 scenario in practice, we turn to a brief overview of the Mesh itself. 824 At the simplest level, the Mesh is simply a tool that allows a user 825 to bind all their disparate electronic devices into one logical unit 826 by means of cryptographic credentials that are in normal 827 circumstances hidden from the user?s view. 829 To begin using the Mesh, Alice first creates a personal profile and 830 registers it to a CryptoMesh portal. Alice?s personal profile 831 contains a master profile containing a set of administrative keys 832 that are used to sign updates to the personal profile and master 833 signature key that is used to sign the master profile itself. The 834 fingerprint of the master signature key is the user?s personal mesh 835 fingerprint. 837 meshman /personal alice@prismproof.org "Alice Example" 838 Fingerprint: MCCW5-PYAX5-ZJ2TU-BVYT6-5Z3E6-DYA3I 840 Figure 6 842 A real-life Hollywood Alice would probably use an app on her 843 smartphone for this purpose. For this paper, the command line tool 844 to illustrate examples is more convenient. 846 The Cryptomesh is envisaged as an open co-operative infrastructure 847 for management of public Mesh profiles. The CryptoMesh cannot suffer 848 a confidentiality breach as all the data submitted to or created by 849 the CryptoMesh is public. End-to-end confidentiality of private 850 components of personal profiles is achieved by use of strong 851 cryptography. 853 Use of the CryptoMesh provides the typical user with all the 854 advantages of a cloud service without the usual disadvantage of being 855 tied to a single cloud provider. Users may change their Mesh portal 856 at any time without notice. All the information that is stored in 857 the CryptoMesh is also stored on the user?s personal devices. 859 A user is not even required to use the CryptoMesh at all. Though any 860 party who is security conscious enough to want to run their own 861 private Mesh portal is likely to appreciate the fact that compromise 862 of the private portal while undesirable will not result in a breach 863 of the applications it is used to support. 865 4.1. Connecting Devices 867 Having created her personal profile on one of her devices, Alice?s 868 next action is to connect more devices, her new DSLR camera for 869 example. To do this, she simply runs the Mesh administration tool on 870 the new device and specifies the name of the profile to connect to. 871 The tool fetches the personal profile from the portal and reports the 872 UDF fingerprint for Alice to check, should she want to do so. 874 meshman /connect alice@example.com 875 Fingerprint: MCCW5-PYAX5-ZJ2TU-BVYT6-5Z3E6-DYA3I 876 Code: VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX 878 Figure 7 880 To complete the process, Alice must confirm the connection request on 881 the first device. The manager provides a list of pending connection 882 requests. 884 meshman /pending 885 Code: VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX 886 Description: Nikon D850 888 Figure 8 890 Alice verifies that the connection request has the same comparison 891 identifier. This identifier is a fingerprint of Alice?s personal 892 mesh fingerprint and the fingerprint of the new device profile. Thus 893 if the identifiers match, mutual authentication is achieved and Alice 894 accepts the request: 896 meshman /accept VC25D 897 Accepted VC25D-QFQE4-OU4VJ-QNPGT-S7V25-QB3JX 899 Figure 9 901 Given an appropriately secured booking system, Alice?s hire car may 902 be connected to her personal profile automatically but only for the 903 limited purpose of receiving commands and preferences from Alice and 904 her connected devices. For the period of the rental, the hire car 905 responds to Alice as its trusted user. 907 4.2. Connecting Applications 909 Having connected her devices, Alice begins connecting applications. 910 Alice wants all the devices she has connected thus far to have secure 911 email, SSH credential management and Web credential management: 913 meshman /mail alice@example.com 914 meshman /ssh 915 meshman /web 917 Figure 10 919 The Mesh approach to usability is to ask as little of the user as 920 possible. Why bother to ask the user if they want S/MIME or OpenPGP 921 credentials when it is as easy to provide both? 923 Alice connects her cloud storage provider to her personal profile, 924 thus enabling its use by any of her devices that require data 925 storage. 927 4.3. Contacts Directory 929 Having briefly described the Mesh itself, we may describe the use of 930 the Mesh to support naming infrastructures. One such application is 931 the use of a shared contacts directory across connected devices. 932 This allows the user to create personal names or shortcuts for all 933 the people and devices they might interact with. 935 Alice has created shortcuts in her Mesh contacts directory for ?Bob? 936 and ?Carol?. These shortcuts allowed her to establish the conference 937 call with a voice command. 939 5. Acknowledgements 941 The ideas in this paper were developed over several years with the 942 aid of Melih Abdulhayoglu, Robin Alden, Rob Stradling and Egemen Tas. 944 6. Security Considerations 946 This document describes the use of identifiers in the Mathematical 947 Mesh and the security concerns that this gives rise to. The concepts 948 of Expectations, Work Factor and Authority are explored. 950 6.1. Expectations 952 Whenever humans are required to interact with an identifier, their 953 reasonable expectations must be met. Rather too often, it is the 954 protocol designer?s expectations of the user rather than the user?s 955 expectations of the protocol that have been primary. 957 6.2. Work Factor 959 No security infrastructure is invulnerable. Given infinite computing 960 resources, even the strongest code can be broken. What matters is 961 how difficult the security infrastructure is to break. When 962 considering the strength of a cryptographic algorithm we consider the 963 work factor measured in operations. Work factors of 2128 or greater 964 are generally considered to be prohibitively difficult to break if 965 the algorithm is secure regardless of future computing advances. 966 Work factors of 2256 or greater present a generous safety margin. 968 Unfortunately, the cryptography used in a security system is rarely 969 the weakest link. Thus, when considering systems rather than 970 algorithms, an estimate of cost (i.e. in dollars or other currency) 971 is more informative. The architecture of the WebPKI was originally 972 developed using a work factor based on the estimated cost of 973 obtaining a false credential and the expected criminal gain. 974 Deterrence is achieved when the apparent cost is greater than the 975 apparent gain. 977 As noted in a previous paper [draft-hallambaker-prismproof-trust] 978 [draft-hallambaker-prismproof-trust] , linked notary log technology 979 (aka Blockchain) makes the cost of a backdating attack, near 980 infinite. This property may be used to advantage in developing a 981 naming infrastructure. 983 6.3. Authority 985 The use of any identifier whose interpretation relies on the action 986 of an external authority raises the problem of delegating trust. The 987 problem is the same whether the authority be a single entity (e.g. 988 ICANN) or multiple entities (e.g. WebPKI Certificate Authorities). 990 Terms of debate which allow one type of authority to be attacked 991 relentlessly while holding the other as unimpeachable are 992 unacceptable and must be discarded. Any party that proposes to act 993 as an authority in any form of naming scheme must accept that they 994 are accountable to the community they serve. 996 The approach described in this paper does not eliminate the authority 997 problem but does allow it to be confined to the problem of mapping 998 human interaction identifiers to other forms of identifier. Secure 999 Internet Names are identifiers that are bound to a specific security 1000 policy governing their interpretation, allowing the role of any 1001 authority to be absolutely circumscribed. 1003 7. IANA Considerations 1005 This document has no considerations for IANA. 1007 8. Informative References 1009 [draft-hallambaker-mesh-architecture] 1010 Hallam-Baker, P., "Mathematical Mesh: Architecture", 1011 draft-hallambaker-mesh-architecture-03 (work in progress), 1012 May 2017. 1014 [draft-hallambaker-prismproof-trust] 1015 Hallam-Baker, P., "PRISM Proof Trust Model", draft- 1016 hallambaker-prismproof-trust-01 (work in progress), 1017 October 2014. 1019 [draft-hallambaker-udf] 1020 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 1021 hallambaker-udf-05 (work in progress), May 2017. 1023 [FedRes2016] 1024 Federal Reserve, "The Federal Reserve Payments Study 1025 2016", December 2016. 1027 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1028 for Internationalized Domain Names in Applications 1029 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003. 1031 [RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet 1032 X.509 Public Key Infrastructure: Logotypes in X.509 1033 Certificates", RFC 3709, DOI 10.17487/RFC3709, February 1034 2004. 1036 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1037 Resource Identifier (URI): Generic Syntax", STD 66, 1038 RFC 3986, DOI 10.17487/RFC3986, January 2005. 1040 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 1041 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006. 1043 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1044 of Named Entities (DANE) Transport Layer Security (TLS) 1045 Protocol: TLSA", RFC 6698, August 2012. 1047 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1048 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 1050 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1051 Keranen, A., and P. Hallam-Baker, "Naming Things with 1052 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013. 1054 Author's Address 1056 Phillip Hallam-Baker 1057 Comodo Group Inc. 1059 Email: philliph@comodo.com