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