idnits 2.17.1 draft-birk-pep-trustwords-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2019) is 1755 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) ** Downref: Normative reference to an Informational RFC: RFC 4949 == Outdated reference: A later version (-06) exists of draft-birk-pep-03 == Outdated reference: A later version (-01) exists of draft-hoeneisen-pep-keysync-00 == Outdated reference: A later version (-05) exists of draft-marques-pep-handshake-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Hoeneisen 3 Internet-Draft Ucom.ch 4 Intended status: Standards Track H. Marques 5 Expires: January 9, 2020 pEp Foundation 6 July 08, 2019 8 IANA Registration of Trustword Lists: Guide, Template and IANA 9 Considerations 10 draft-birk-pep-trustwords-04 12 Abstract 14 This document specifies the IANA Registration Guidelines for 15 Trustwords, describes corresponding registration procedures, and 16 provides a guideline for creating Trustword list specifications. 18 Trustwords are common words in a natural language (e.g., English), 19 which hexadecimal strings are mapped to. Such a mapping makes 20 verification processes like fingerprint comparisons more practical, 21 and less prone to misunderstandings. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Concept of Trustword Mapping . . . . . . . . . . . . . . 4 61 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Previous work . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Number of Trustwords for a language . . . . . . . . . . . 5 64 2.4. Language . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.5. The nature of the words . . . . . . . . . . . . . . . . . 6 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Registration Template (XML chunk) . . . . . . . . . . . . 6 70 5.2. IANA Registration . . . . . . . . . . . . . . . . . . . . 8 71 5.2.1. Language Code () . . . . . . . . . . . 8 72 5.2.2. Bit Size () . . . . . . . . . . . . . . . . 8 73 5.2.3. Number Of Unique Words () . . . 8 74 5.2.4. Bijectivity () . . . . . . . . . . . . . . 8 75 5.2.5. Version () . . . . . . . . . . . . . . . . . 8 76 5.2.6. Registration Document(s) () . . . . 9 77 5.2.7. Requesters () . . . . . . . . . . . . . . 9 78 5.2.8. Further Information () . . . . . . . 9 79 5.2.9. Wordlist () . . . . . . . . . . . . . . . . 10 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 7.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. IANA XML Template Example . . . . . . . . . . . . . 12 85 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 13 86 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 In public-key cryptography, comparing the respective public key 92 fingerprints for each of the communication partners involved is vital 93 to ensure that there is no Man-in-the-Middle (MITM) attack on the 94 communication channel. These fingerprints normally consist of a 95 chain of hexadecimal characters, which are often impractical, 96 cumbersome, and prone to misunderstandings for end-users. 98 To mitigate these challenges, several systems offer Trustword 99 comparison as an alternative to these hexadecimal strings. 100 Trustwords are common words in a natural language (e.g., English), 101 which these hexadecimal strings are mapped to. Using Trustwords 102 makes verification processes like fingerprint comparisons more 103 natural for users. 105 For example, in pEp's Privacy by Default proposition [I-D.birk-pep] 106 Trustwords are used to facilitate easy contact verification for end- 107 to-end encryption. Trustword comparison is offered after the peers 108 have opportunistically exchanged public keys. Examples of Trustword 109 lists used by current pEp implementations can be found here in CSV 110 format: https://pep.foundation/dev/repos/pEpEngine/file/tip/db. 112 In addition to contact verification, Trustwords are also used for 113 other purposes, such as Human-Readable 128-bit Keys [RFC1751], One 114 Time Passwords (OTP) [RFC1760] [RFC2289], SSH host-key verification, 115 VPN server certificate verification, deriving private keys in 116 blockchain applications for cryptocurrencies, and to import or 117 synchronize secret keys across multiple devices owned by a single 118 user [I-D.hoeneisen-pep-keysync]. Further ideas include the use of 119 Trustwords for private key recovery in case of loss, contact 120 verification in Extensible Messaging and Presence Protocol (XMPP) 121 [RFC6120], or for X.509 certificate verification in browsers 122 [RFC3647]. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 1.2. Terms 132 The following terms are defined for the scope of this document: 134 o pEp Handshake: The process of one user contacting another over an 135 independent channel in order to verify Trustwords (or by fallback: 136 fingerprints). This can be done in-person or through established 137 verbal communication channels, like a phone call. 138 [I-D.marques-pep-handshake] 140 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 141 form of active wiretapping attack in which the attacker intercepts 142 and selectively modifies communicated data to masquerade as one or 143 more of the entities involved in a communication association." 145 2. The Concept of Trustword Mapping 147 2.1. Example 149 As already discussed, fingerprints normally consist of a string of 150 hexadecimal characters. A typical fingerprint looks like this: 152 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 154 Instead of the hexadecimal string, Trustwords allow users to compare 155 ten common words of a language of their choosing. For example, the 156 above fingerprint, mapped to English Trustwords, might appear as: 158 dog house brother town fat bath school banana kite task 160 The same fingerprint might appear in German Trustwords as: 162 klima gelb lappen weg trinken alles kaputt rasen rucksack durch 164 Note: These examples are for illustration purposes only, and are not 165 derived from any published Trustword list. 167 2.2. Previous work 169 The basic concept of Trustword mapping - also known as a biometric 170 word list - for fingerprint comparison is well-documented. Examples 171 of this concept are used with One-Time Passwords (OTP) [RFC1751] 172 [RFC1760] [RFC2289], as well as the PGP Word List ("Pretty Good 173 Privacy word list" [PGP.wl]. Furthermore, cryptocurrencies use a 174 similar concept for deriving private keys [bitcoin.wl]. 176 [[ TODO: Explain each previous usage a bit further and synchronize 177 with section Section 1. ]] 179 Regarding today's needs, previous proposals have the following 180 shortcomings: 182 o Small/limited word lists, which generally result in more words to 183 compare 185 o Existing word lists are usually only available in English, which 186 limits their usefulness for non-English speakers 188 Furthermore, there are differences in the basic concept: 190 o The Trustword concept suggested herein intends to improve 191 usability and security for all users, instead of only the 192 technically-savvy. 194 o In many use cases, Trustwords are only read (aloud) during the 195 comparison process, rather than being written or typed. For 196 example, two users might compare their respective Trustwords 197 during a phone call. Verbal comparison reduces the need to keep 198 the actual Trustwords short. The use of longer Trustwords 199 increases the entropy within the system, as it allows for a larger 200 dictionary, and thus reduces the likelihood of phonetic 201 collisions. 203 2.3. Number of Trustwords for a language 205 If the number of Trustwords in a dictionary is low, shorter parts of 206 the original string (e.g., fingerprint) can be mapped to a single 207 Trustword. Thus, many Trustwords will need to be compared, which 208 results in a potentially cumbersome process for users, and lead to 209 reduced usability. 211 To reduce the number of Trustwords that need to be compared, pEp's 212 Privacy by Default proposition [I-D.birk-pep] calls for 16-bit 213 scalars to be mapped to natural language words. Therefore, the size 214 (by number of key-value pairs) of any key-value pair structure is 215 65536. However, the number of unique values to be used in a language 216 may be smaller than this number. This discrepancy can be addressed 217 by using the same value, or Trustword, for more than one key. In 218 such cases, the entropy of the representation is slightly reduced. 219 For example, a Trustword list of 42000 words still allows for an 220 entropy of log_2(42000), which is roughly 15.36 bits in 16-bit 221 mappings. As a consequence such Trustword lists are not bijective. 223 On the other hand, small Trustword lists allow for Trustwords 224 consisting of words with shorter strings (number of short words per 225 natural language is normally limited), which are easier to use in 226 implementations where Trustwords have to be typed or written, such as 227 in OTP applications. 229 Note: This specification allows for registration of variable numbers 230 of Trustwords per dictionary. 232 2.4. Language 234 Although English is used around the world, the vast majority of the 235 global population is not English-speaking. For an application to be 236 useful to as wide of a user base as possible, localization is 237 essential. Therefore, this specification allows for registration of 238 Trustword lists in different languages. 240 In applications where two humans are attempting to establish secure 241 communications, it is likely that they share a common language. At 242 this time, no real-world use cases for Trustword list translation 243 capability have been identified. Because the translation process 244 inherently - and drastically - increases complexity from an IANA 245 registration standpoint, the topic of Trustword translation is beyond 246 the scope of this document. 248 2.5. The nature of the words 250 Every Trustword list SHOULD be clear of offensive language (i.e., 251 swear/curse words, slurs, derogatory language, etc.). This process 252 SHOULD be performed by native speakers of each respective language. 254 3. Security Considerations 256 There are no specific security considerations. 258 4. Privacy Considerations 260 [[ TODO ]] 262 5. IANA Considerations 264 Each natural language requires a different set of Trustwords. To 265 allow implementers for identical Trustword lists, a IANA registry is 266 to be established. The IANA registration policy according to 267 [RFC8126] is "Expert Review" and "Specification Required". 269 [[ Note: Further details of the IANA registry and requirements for 270 the expert to assess the specification are for further study. A 271 similar approach as used in [RFC6117] is likely followed. ]] 273 5.1. Registration Template (XML chunk) 275 276 277 278 279 280 282 283 284 286 287 288 291 292 293 295 296 297 298 299 300 301 302 303 304 305 306 307 309 310 311 312 313 314 315 316 first 317 second 318 [...] 319 last 320 321 323 324 325 326 327 328 329 330 331 333 Authors of a Wordlist are encouraged to use these XML chunks as a 334 template to create the IANA Registration Template. 336 5.2. IANA Registration 338 An IANA registration will contain the fallowing elements: 340 5.2.1. Language Code () 342 The language code follows the ISO 639-3 specification [ISO639], e.g., 343 eng, deu. 345 [[ Note: It is for further study, which of the ISO 639 Specifications 346 is most suitable to address the Trustwords' challenge. ]] 348 Example usage for German: 350 e.g. deu 352 5.2.2. Bit Size () 354 The bit size is the number of bits that can be mapped with the 355 Wordlist. The number of registered words in a word list MUST be 2 ^ 356 "()". 358 Example usage for 16-bit Wordlist: 360 e.g. 16 362 5.2.3. Number Of Unique Words () 364 The number of unique words that are registered. 366 e.g. 65536 368 5.2.4. Bijectivity () 370 Whether the registered Wordlist has a one-to-one mapping, meaning the 371 number of unique words registered equals 2 ^ "()". 373 Valid content: ( yes | no ) 375 e.g. yes 377 5.2.5. Version () 379 The version of the Wordlist MUST be unique within a language code. 381 [[ Note: Requirements to a "smart" composition of the version number 382 are for further study ]] 383 e.g. b.1.2 385 5.2.6. Registration Document(s) () 387 Reference(s) to the Document(s) containing the Wordlist 389 e.g. 390 391 393 e.g. 394 (obsoleted by RFC 9999) 395 396 398 e.g. 399 [International Telecommunications Union, 400 "Wordlist for Foobar application", 401 ITU-F Recommendation B.193, Release 73, Mar 2009.] 402 404 5.2.7. Requesters () 406 The persons requesting the registration of the Wordlist. Usually 407 these are the authors of the Wordlist. 409 e.g. 410 411 413 414 415 John Doe 416 Example Inc. 417 mailto:john.doe@example.com 418 2018-06-20 419 420 422 Note: If there is more than one requester, there must be one 423 element per requester in the element, and one 424 chunk per requester in the element. 426 5.2.8. Further Information () 428 Any other information the authors deem interesting. 430 e.g. 431 more info goes here 432 434 Note: If there is no such additional information, then the 435 element is omitted. 437 5.2.9. Wordlist () 439 The full Wordlist to be registered. The number of words MUST be a 440 power of 2 as specified above. The element names serve as key used 441 for enumeration of the Trustwords (starting at 0) and the elements 442 contains the values being individual natural language words in the 443 respective language. 445 e.g. 446 first 447 second 448 [...] 449 last 450 452 ] ]> 454 [[ Note: The exact representation of the Wordlist is for further 455 study. ]] 457 6. Acknowledgments 459 The authors would like to thank the following people who have 460 provided feedback or significant contributions to the development of 461 this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore, 462 Kelly Bristol, Michael Richardson, Rich Salz, Volker Birk, and Yoav 463 Nir. 465 This work was initially created by pEp Foundation, and then reviewed 466 and extended with funding by the Internet Society's Beyond the Net 467 Programme on standardizing pEp. [ISOC.bnet] 469 7. References 471 7.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 479 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 480 . 482 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 483 Writing an IANA Considerations Section in RFCs", BCP 26, 484 RFC 8126, DOI 10.17487/RFC8126, June 2017, 485 . 487 7.2. Informative References 489 [bitcoin.wl] 490 "Seed Phrase", June 2019, . 493 [I-D.birk-pep] 494 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 495 Privacy by Default", draft-birk-pep-03 (work in progress), 496 March 2019. 498 [I-D.hoeneisen-pep-keysync] 499 Hoeneisen, B. and H. Marques, "pretty Easy privacy (pEp): 500 Key Synchronization Protocol", draft-hoeneisen-pep- 501 keysync-00 (work in progress), July 2019. 503 [I-D.marques-pep-handshake] 504 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 505 Contact and Channel Authentication through Handshake", 506 draft-marques-pep-handshake-03 (work in progress), July 507 2019. 509 [ISO639] "Language codes - ISO 639", n.d., 510 . 512 [ISOC.bnet] 513 Simao, I., "Beyond the Net. 12 Innovative Projects 514 Selected for Beyond the Net Funding. Implementing Privacy 515 via Mass Encryption: Standardizing pretty Easy privacy's 516 protocols", June 2017, . 520 [PGP.wl] "PGP word list", November 2017, 521 . 524 [RFC1751] McDonald, D., "A Convention for Human-Readable 128-bit 525 Keys", RFC 1751, DOI 10.17487/RFC1751, December 1994, 526 . 528 [RFC1760] Haller, N., "The S/KEY One-Time Password System", 529 RFC 1760, DOI 10.17487/RFC1760, February 1995, 530 . 532 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 533 Time Password System", STD 61, RFC 2289, 534 DOI 10.17487/RFC2289, February 1998, 535 . 537 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 538 Wu, "Internet X.509 Public Key Infrastructure Certificate 539 Policy and Certification Practices Framework", RFC 3647, 540 DOI 10.17487/RFC3647, November 2003, 541 . 543 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 544 Registration of Enumservices: Guide, Template, and IANA 545 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 546 2011, . 548 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 549 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 550 March 2011, . 552 Appendix A. IANA XML Template Example 554 This section contains a non-normative example of the IANA 555 Registration Template XML chunk. 557 558 lat 559 16 560 57337 561 no 562 n.0.1 563 564 565 566 567 568 569 570 571 This Wordlist has been optimized for 572 the Roman Standards Process. 573 574 575 576 errare 577 humanum 578 [...] 579 est 580 581 583 584 585 Julius Caesar 586 Curia Romana 587 mailto:julius.cesar@example.com 588 1999-12-31 589 590 592 Appendix B. Document Changelog 594 [[ RFC Editor: This section is to be removed before publication ]] 596 o draft-birk-pep-trustwords-04: 598 * Add Privacy Considerations section 600 * Swapped Security and IANA Consideration Sections 602 * Corrected typo in ISO references 604 * Updated Introduction, Terms and concept Sections 606 o draft-birk-pep-trustwords-03: 608 * Update references 610 * Minor edits 612 o draft-birk-pep-trustwords-02: 614 * Minor editorial changes and bug fixes 616 * Added more items to Open Issues 618 * Add usage example 620 o draft-birk-pep-trustwords-01: 622 * Included feedback from mailing list and IETF-101 SECDISPATCH 623 WG, e.g. 625 + Added more explanatory text / less focused on the main use 626 case 628 + Bit size as parameter 630 * Explicitly stated translations are out-of-scope for this 631 document 633 * Added draft IANA XML Registration template, considerations, 634 explanation and examples 636 * Added Changelog to Appendix 638 * Added Open Issue section to Appendix 640 Appendix C. Open Issues 642 [[ RFC Editor: This section should be empty and is to be removed 643 before publication. ]] 645 o Better explain previous work on Trustwords 647 o More explanatory text for Trustword use cases, properties and 648 requirements 650 o Further details of the IANA registry and requirements for the 651 expert to assess the specification 653 o Decide which ISO language code either 639-1 or 639-3 to use, i.e., 654 ISO-639-1 (e.g., ca, de, en, ...) as currently used in pEp 655 implementations (running code) or ISO-639-3 (eng, deu, ita, ...) 657 o Adjust exact representation of wordlists 659 * e.g. XML, CSV, ... 661 * Syntax for non-ASCII letters or language symbols (UTF-8) in 662 Wordlists 664 o Need for optional entropy value assigned to words, to account for 665 similar phonetics among words in the same wordlist? 667 o Need for an additional field, to define what a wordlist is 668 optimized for, e.g., "entropy", "minimize word lengths", ...? 670 o Work out (requirements for) "smart" composition of the version 671 number 673 o Decide whether in non-bijective Wordlists the redundant words need 674 to be repeated in the IANA Registration 676 o Register only a hash over the wordlist with IANA? 678 o Does it make sense to open registrations for other patterns than 679 just words, e.g., images? 681 Authors' Addresses 683 Bernie Hoeneisen 684 Ucom Standards Track Solutions GmbH 685 CH-8046 Zuerich 686 Switzerland 688 Phone: +41 44 500 52 40 689 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 690 URI: https://ucom.ch/ 692 Hernani Marques 693 pEp Foundation 694 Oberer Graben 4 695 CH-8400 Winterthur 696 Switzerland 698 Email: hernani.marques@pep.foundation 699 URI: https://pep.foundation/