idnits 2.17.1 draft-birk-pep-trustwords-03.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 (March 11, 2019) is 1874 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 (-05) exists of draft-marques-pep-handshake-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Birk 3 Internet-Draft H. Marques 4 Intended status: Standards Track pEp Foundation 5 Expires: September 12, 2019 B. Hoeneisen 6 Ucom.ch 7 March 11, 2019 9 IANA Registration of Trustword Lists: Guide, Template and IANA 10 Considerations 11 draft-birk-pep-trustwords-03 13 Abstract 15 This document specifies the IANA Registration Guidelines for 16 Trustwords, describes corresponding registration procedures, and 17 provides a guideline for creating Trustword list specifications. 19 Trustwords are common words in a natural language (e.g., English) to 20 which the hexadecimal strings are mapped to. This makes verification 21 processes (e.g., comparison of fingerprints), more practical and less 22 prone to misunderstandings. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 12, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. The Concept of Trustword Mapping . . . . . . . . . . . . . . 3 61 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Previous work . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Number of Trustwords for a language . . . . . . . . . . . 4 64 3.4. Language . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.5. The nature of the words . . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Registration Template (XML chunk) . . . . . . . . . . . . 6 68 4.2. IANA Registration . . . . . . . . . . . . . . . . . . . . 7 69 4.2.1. Language Code () . . . . . . . . . . . 7 70 4.2.2. Bit Size () . . . . . . . . . . . . . . . . 7 71 4.2.3. Number Of Unique Words () . . . 7 72 4.2.4. Bijectivity () . . . . . . . . . . . . . . 8 73 4.2.5. Version () . . . . . . . . . . . . . . . . . 8 74 4.2.6. Registration Document(s) () . . . . 8 75 4.2.7. Requesters () . . . . . . . . . . . . . . 8 76 4.2.8. Further Information () . . . . . . . 9 77 4.2.9. Wordlist () . . . . . . . . . . . . . . . . 9 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. IANA XML Template Example . . . . . . . . . . . . . 12 84 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 12 85 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 In public-key cryptography comparing the public keys' fingerprints of 91 the communication partners involved is vital to ensure that there is 92 no man-in-the-middle (MITM) attack on the communication channel. 93 Fingerprints normally consist of a chain of hexadecimal chars. 94 However, comparing hexadecimal strings is often impractical for 95 regular human users and prone to misunderstandings. 97 To mitigate these challenges, several systems offer the comparison of 98 Trustwords as an alternative to hexadecimal strings. Trustwords are 99 common words in a natural language (e.g., English) to which the 100 hexadecimal strings are mapped to. This makes the verification 101 process more natural for human users. 103 For example, in pEp's proposition of Privacy by Default 104 [I-D.birk-pep] Trustwords are used to achieve easy contact 105 verification for end-to-end encryption. Trustword comparison is 106 offered after the peers have exchanged public keys opportunistically. 107 Examples for Trustword lists used by current pEp implementations can 108 be found in CSV format, here: 109 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, and to import or synchronize 115 secret key across different devices of the same user 116 [E-D.birk-pep-keysync]. Further ideas include to use Trustwords for 117 contact verification in Extensible Messaging and Presence Protocol 118 (XMPP) [RFC6120], for X.509 [RFC3647] certificate verification in 119 browsers or in block chain applications for crypto currencies. 121 2. Terms 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 o pEp Handshake: The process when Alice - e.g., in-person or via 128 phone - contacts Bob to verify Trustwords (or by fallback: 129 fingerprints) is called pEp Handshake. 130 [I-D.marques-pep-handshake] 132 o Man-in-the-middle attack (MITM): cf. [RFC4949] 134 3. The Concept of Trustword Mapping 136 3.1. Example 138 A fingerprint typically looks like: 140 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 142 Its mapping to English Trustwords could look like: 144 dog house brother town fat bath school banana kite task 146 Or its mapping to German Trustwords could like like: 148 klima gelb lappen weg trinken alles kaputt rasen rucksack durch 150 Instead of the former hexadecimal string, users can compare ten 151 common words of their language. 153 Note: This examples are for illustration purposes only and do not 154 make use any any published Trustword list. 156 3.2. Previous work 158 The basic concept of Trustwords mapping has been already documented 159 in the past, e.g. for use in One-Time Passwords (OTP) [RFC1751] 160 [RFC1760] [RFC2289] or the PGP Word List ("Pretty Good Privacy word 161 list" [PGP.wl], also called a biometric word list, to compare 162 fingerprints. 164 Regarding today's needs, previous proposals have the following 165 shortcomings: 167 o Limited number of Trustwords (small Trustword dictionaries), which 168 generally results in more Trustwords to be compared 170 o Usually only available in English language, which does not 171 normally allow its usage by non-English speakers in a secure 172 manner 174 Furthermore, there are differences in the basic concept: 176 o This work allows for better tailoring the target audience to 177 ordinary human users, i.e. not technical stuff (or IT geeks) only. 179 o As in many usage scenarios the Trustwords are only read (and 180 compared), but not written down nor typed in by humans, there is a 181 less strong need to keep the Trustwords themselves short. One 182 such scenario is to use a side channel (e.g. phone) to compare the 183 Trustwords. In fact longer Trustwords increases increase the 184 entropy, as the dictionary is larger and the likelihood for 185 phonetic collision can be decreased. 187 3.3. Number of Trustwords for a language 189 If the number of Trustwords is low, a lot of Trustwords need to be 190 compared, which make a comparison somewhat cumbersome for users. 191 This may lead to degraded usability. 193 To reduce the number of Trustwords to compare, in pEp's proposition 194 of Privacy by Default [I-D.birk-pep] 16-bit scalars are mapped to 195 natural language words. Therefore, the size (by number of key - 196 value pairs) of any key - value pair structure is 65536. However, 197 the number of unique values to be used in a language may be less than 198 65536. This can be addressed e.g. by using the same value 199 (Trustword) for more than one key. In these cases, the entropy of 200 the representation is slightly reduced. (Example: A Trustwords list 201 of just 42000 words still allows for an entropy of log_2(42000) ~= 202 15.36 bits in 16-bit mappings.) 204 On the other hand, small sized Trustword lists allow for Trustwords 205 with shorter strings, which are easier to use in scenarios where 206 Trustwords have to be typed in e.g. OTP applications. 208 The specification allows for different dictionary sizes. 210 3.4. Language 212 Although English is rather widespread around the world, the vast 213 majority of the worlds' population does not speak English. For an 214 application to be useful for ordinary people, localization is a must. 215 Thus, Trustword lists in different languages can be registered. 217 For applications where two human establish communication it is very 218 likely that they share a common language. So far no real use case 219 for translations between Trustword lists in different languages has 220 been identified. As translations also drastically increases the 221 complexity for IANA registrations, translations of Trustwords beyond 222 the scope of this document. 224 3.5. The nature of the words 226 Every Trustwords list SHOULD be cleared from swearwords in order to 227 not offense users. This is a task to be carried out by speakers of 228 the respective natural language (i.e., by native language speakers). 230 4. IANA Considerations 232 Each natural language requires a different set of Trustwords. To 233 allow implementers for identical Trustword lists, a IANA registry is 234 to be established. The IANA registration policy according to 235 [RFC8126] is "Expert Review" and "Specification Required". 237 [[ Note: Further details of the IANA registry and requirements for 238 the expert to assess the specification are for further study. A 239 similar approach as used in [RFC6117] is likely followed. ]] 241 4.1. Registration Template (XML chunk) 243 244 245 246 247 248 250 251 252 254 255 256 258 259 260 262 263 264 265 266 267 268 269 270 271 272 273 274 276 277 278 279 280 281 282 283 first 284 second 285 [...] 286 last 287 288 289 290 291 292 293 294 295 296 297 299 Authors of a Wordlist are encouraged to use these XML chunks as a 300 template to create the IANA Registration Template. 302 4.2. IANA Registration 304 An IANA registration will contain the fallowing elements: 306 4.2.1. Language Code () 308 The language code follows the ISO 639-3 specification [ISO693], e.g., 309 eng, deu. 311 [[ Note: It is for further study, which of the ISO 639 Specifications 312 is most suitable to address the Trustwords' challenge. ]] 314 Example usage for German: 316 e.g. deu 318 4.2.2. Bit Size () 320 The bit size is the number of bits that can be mapped with the 321 Wordlist. The number of registered words in a word list MUST be 2 ^ 322 "()". 324 Example usage for 16-bit Wordlist: 326 e.g. 16 328 4.2.3. Number Of Unique Words () 330 The number of unique words that are registered. 332 e.g. 65536 334 4.2.4. Bijectivity () 336 Whether the registered Wordlist has a one-to-one mapping, meaning the 337 number of unique words registered equals 2 ^ "()". 339 Valid content: ( yes | no ) 341 e.g. yes 343 4.2.5. Version () 345 The version of the Wordlist MUST be unique within a language code. 347 [[ Note: Requirements to a "smart" composition of the version number 348 are for further study ]] 350 e.g. b.1.2 352 4.2.6. Registration Document(s) () 354 Reference(s) to the Document(s) containing the Wordlist 356 e.g. 357 358 360 e.g. 361 (obsoleted by RFC 9999) 362 363 365 e.g. 366 [International Telecommunications Union, 367 "Wordlist for Foobar application", 368 ITU-F Recommendation B.193, Release 73, Mar 2009.] 369 371 4.2.7. Requesters () 373 The persons requesting the registration of the Wordlist. Usually 374 these are the authors of the Wordlist. 376 e.g. 377 378 380 381 382 John Doe 383 Example Inc. 384 mailto:john.doe@example.com 385 2018-06-20 386 387 389 Note: If there is more than one requester, there must be one 390 element per requester in the element, and one 391 chunk per requester in the element. 393 4.2.8. Further Information () 395 Any other information the authors deem interesting. 397 e.g. 398 more info goes here 399 401 Note: If there is no such additional information, then the 402 element is omitted. 404 4.2.9. Wordlist () 406 The full Wordlist to be registered. The number of words MUST be a 407 power of 2 as specified above. The element names serve as key used 408 for enumeration of the Trustwords (starting at 0) and the elements 409 contains the values being individual natural language words in the 410 respective language. 412 e.g. 413 first 414 second 415 [...] 416 last 417 419 ] ]> 421 [[ Note: The exact representation of the Wordlist is for further 422 study. ]] 424 5. Security Considerations 426 There are no special security considerations. 428 6. Acknowledgements 430 The authors would like to thank the following people who have 431 provided feedback or significant contributions to the development of 432 this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore, 433 Michael Richardson, Rich Salz, and Yoav Nir. 435 This work was initially created by pEp Foundation, and then reviewed 436 and extended with funding by the Internet Society's Beyond the Net 437 Programme on standardizing pEp. [ISOC.bnet] 439 7. References 441 7.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 449 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 450 . 452 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 453 Writing an IANA Considerations Section in RFCs", BCP 26, 454 RFC 8126, DOI 10.17487/RFC8126, June 2017, 455 . 457 7.2. Informative References 459 [E-D.birk-pep-keysync] 460 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key 461 Synchronization Protocol", June 2018, 462 . 466 Early draft 468 [I-D.birk-pep] 469 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 470 Privacy by Default", draft-birk-pep-03 (work in progress), 471 March 2019. 473 [I-D.marques-pep-handshake] 474 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 475 Contact and Channel Authentication through Handshake", 476 draft-marques-pep-handshake-01 (work in progress), October 477 2018. 479 [ISO693] "Language codes - ISO 639", n.d., 480 . 482 [ISOC.bnet] 483 Simao, I., "Beyond the Net. 12 Innovative Projects 484 Selected for Beyond the Net Funding. Implementing Privacy 485 via Mass Encryption: Standardizing pretty Easy privacy's 486 protocols", June 2017, . 490 [PGP.wl] "PGP word list", November 2017, 491 . 494 [RFC1751] McDonald, D., "A Convention for Human-Readable 128-bit 495 Keys", RFC 1751, DOI 10.17487/RFC1751, December 1994, 496 . 498 [RFC1760] Haller, N., "The S/KEY One-Time Password System", 499 RFC 1760, DOI 10.17487/RFC1760, February 1995, 500 . 502 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 503 Time Password System", STD 61, RFC 2289, 504 DOI 10.17487/RFC2289, February 1998, 505 . 507 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 508 Wu, "Internet X.509 Public Key Infrastructure Certificate 509 Policy and Certification Practices Framework", RFC 3647, 510 DOI 10.17487/RFC3647, November 2003, 511 . 513 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 514 Registration of Enumservices: Guide, Template, and IANA 515 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 516 2011, . 518 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 519 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 520 March 2011, . 522 Appendix A. IANA XML Template Example 524 This section contains a non-normative example of the IANA 525 Registration Template XML chunk. 527 528 lat 529 16 530 57337 531 no 532 n.0.1 533 534 535 536 537 538 539 540 541 This Wordlist has been optimized for 542 the Roman Standards Process. 543 544 545 546 errare 547 humanum 548 [...] 549 est 550 551 553 554 555 Julius Caesar 556 Curia Romana 557 mailto:julius.cesar@example.com 558 1999-12-31 559 560 562 Appendix B. Document Changelog 564 [[ RFC Editor: This section is to be removed before publication ]] 566 o draft-birk-pep-trustwords-02: 568 * Minor editorial changes and bug fixes 569 * Added more items to Open Issues 571 * Add usage example 573 o draft-birk-pep-trustwords-01: 575 * Included feedback from mailing list and IETF-101 SECDISPATCH 576 WG, e.g. 578 + Added more explanatory text / less focused on the main use 579 case 581 + Bit size as parameter 583 * Explicitly stated translations are out-of-scope for this 584 document 586 * Added draft IANA XML Registration template, considerations, 587 explanation and examples 589 * Added Changelog to Appendix 591 * Added Open Issue section to Appendix 593 Appendix C. Open Issues 595 [[ RFC Editor: This section should be empty and is to be removed 596 before publication ]] 598 o More explanatory text for Trustword use cases, properties and 599 requirements 601 o Further details of the IANA registry and requirements for the 602 expert to assess the specification 604 o Decide which ISO language code either 639-1 or 639-3 to use, i.e., 605 ISO-639-1 (e.g., ca, de, en, ...) as currently used in pEp 606 implementations (running code) or ISO-693-3 (eng, deu, ita, ...) 608 o Adjust exact representation of wordlists 610 * e.g. XML, CSV, ... 612 * Syntax for non-ASCII letters or language symbols (UTF-8) in 613 Wordlists 615 o Need for optional entropy value assigned to words, to account for 616 similar phonetics among words in the same wordlist? 618 o Need for an additional field, to define what a wordlist is 619 optimized for, e.g., "entropy", "minimize word lengths", ...? 621 o Work out (requirements for) "smart" composition of the version 622 number 624 o Decide whether in non-bijective Wordlists the redundant words need 625 to be repeated in the IANA Registration 627 o Register only a hash over the wordlist with IANA? 629 o Does it make sense to open registrations for other patterns than 630 just words, e.g., images? 632 o Create terms section by file inclusion - cf. other drafts 634 Authors' Addresses 636 Volker Birk 637 pEp Foundation 638 Oberer Graben 4 639 CH-8400 Winterthur 640 Switzerland 642 Email: volker.birk@pep.foundation 643 URI: https://pep.foundation/ 645 Hernani Marques 646 pEp Foundation 647 Oberer Graben 4 648 CH-8400 Winterthur 649 Switzerland 651 Email: hernani.marques@pep.foundation 652 URI: https://pep.foundation/ 654 Bernie Hoeneisen 655 Ucom Standards Track Solutions GmbH 656 CH-8046 Zuerich 657 Switzerland 659 Phone: +41 44 500 52 44 660 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 661 URI: https://ucom.ch/