idnits 2.17.1 draft-birk-pep-trustwords-02.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 (June 26, 2018) is 2131 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-01 Summary: 1 error (**), 0 flaws (~~), 2 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: December 28, 2018 B. Hoeneisen 6 Ucom.ch 7 June 26, 2018 9 IANA Registration of Trustword Lists: Guide, Template and IANA 10 Considerations 11 draft-birk-pep-trustwords-02 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 December 28, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 13 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 Handshake: The process when Alice - e.g. in-person or via phone - 128 contacts Bob to verify Trustwords (or by fallback: fingerprints) 129 is called handshake. [E-D.birk-pep-handshake] 131 o Man-in-the-middle attack (MITM): cf. [RFC4949] 133 3. The Concept of Trustword Mapping 135 3.1. Example 137 A fingerprint typically looks like: 139 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 141 Its mapping to English Trustwords could look like: 143 dog house brother town fat bath school banana kite task 145 Or its mapping to German Trustwords could like like: 147 klima gelb lappen weg trinken alles kaputt rasen rucksack durch 149 Instead of the former hexadecimal string, users can compare ten 150 common words of their language. 152 Note: This examples are for illustration purposes only and do not 153 make use any any published Trustword list. 155 3.2. Previous work 157 The basic concept of Trustwords mapping has been already documented 158 in the past, e.g. for use in One-Time Passwords (OTP) [RFC1751] 159 [RFC1760] [RFC2289] or the PGP Word List ("Pretty Good Privacy word 160 list" [PGP.wl], also called a biometric word list, to compare 161 fingerprints. 163 Regarding today's needs, previous proposals have the following 164 shortcomings: 166 o Limited number of Trustwords (small Trustword dictionaries), which 167 generally results in more Trustwords to be compared 169 o Usually only available in English language, which does not 170 normally allow its usage by non-English speakers in a secure 171 manner 173 Furthermore, there are differences in the basic concept: 175 o This work allows for better tailoring the target audience to 176 ordinary human users, i.e. not technical stuff (or IT geeks) only. 178 o As in many usage scenarios the Trustwords are only read (and 179 compared), but not written down nor typed in by humans, there is a 180 less strong need to keep the Trustwords themselves short. One 181 such scenario is to use a side channel (e.g. phone) to compare the 182 Trustwords. In fact longer Trustwords increases increase the 183 entropy, as the dictionary is larger and the likelihood for 184 phonetic collision can be decreased. 186 3.3. Number of Trustwords for a language 188 If the number of Trustwords is low, a lot of Trustwords need to be 189 compared, which make a comparison somewhat cumbersome for users. 190 This may lead to degraded usability. 192 To reduce the number of Trustwords to compare, in pEp's proposition 193 of Privacy by Default [I-D.birk-pep] 16-bit scalars are mapped to 194 natural language words. Therefore, the size (by number of key - 195 value pairs) of any key - value pair structure is 65536. However, 196 the number of unique values to be used in a language may be less than 197 65536. This can be addressed e.g. by using the same value 198 (Trustword) for more than one key. In these cases, the entropy of 199 the representation is slightly reduced. (Example: A Trustwords list 200 of just 42000 words still allows for an entropy of log_2(42000) ~= 201 15.36 bits in 16-bit mappings.) 203 On the other hand, small sized Trustword lists allow for Trustwords 204 with shorter strings, which are easier to use in scenarios where 205 Trustwords have to be typed in e.g. OTP applications. 207 The specification allows for different dictionary sizes. 209 3.4. Language 211 Although English is rather widespread around the world, the vast 212 majority of the worlds' population does not speak English. For an 213 application to be useful for ordinary people, localization is a must. 214 Thus, Trustword lists in different languages can be registered. 216 For applications where two human establish communication it is very 217 likely that they share a common language. So far no real use case 218 for translations between Trustword lists in different languages has 219 been identified. As translations also drastically increases the 220 complexity for IANA registrations, translations of Trustwords beyond 221 the scope of this document. 223 3.5. The nature of the words 225 Every Trustwords list SHOULD be cleared from swearwords in order to 226 not offense users. This is a task to be carried out by speakers of 227 the respective natural language (i.e., by native language speakers). 229 4. IANA Considerations 231 Each natural language requires a different set of Trustwords. To 232 allow implementers for identical Trustword lists, a IANA registry is 233 to be established. The IANA registration policy according to 234 [RFC8126] is "Expert Review" and "Specification Required". 236 [[ Note: Further details of the IANA registry and requirements for 237 the expert to assess the specification are for further study. A 238 similar approach as used in [RFC6117] is likely followed. ]] 240 4.1. Registration Template (XML chunk) 242 243 244 245 246 247 249 250 251 253 254 255 257 258 259 261 262 263 264 265 266 267 268 269 270 271 272 273 275 276 277 278 279 280 281 282 first 283 second 284 [...] 285 last 286 287 288 289 290 291 292 293 294 295 296 298 Authors of a Wordlist are encouraged to use these XML chunks as a 299 template to create the IANA Registration Template. 301 4.2. IANA Registration 303 An IANA registration will contain the fallowing elements: 305 4.2.1. Language Code () 307 The language code follows the ISO 639-3 specification [ISO693], e.g., 308 eng, deu. 310 [[ Note: It is for further study, which of the ISO 639 Specifications 311 is most suitable to address the Trustwords' challenge. ]] 313 Example usage for German: 315 e.g. deu 317 4.2.2. Bit Size () 319 The bit size is the number of bits that can be mapped with the 320 Wordlist. The number of registered words in a word list MUST be 2 ^ 321 "()". 323 Example usage for 16-bit Wordlist: 325 e.g. 16 327 4.2.3. Number Of Unique Words () 329 The number of unique words that are registered. 331 e.g. 65536 333 4.2.4. Bijectivity () 335 Whether the registered Wordlist has a one-to-one mapping, meaning the 336 number of unique words registered equals 2 ^ "()". 338 Valid content: ( yes | no ) 340 e.g. yes 342 4.2.5. Version () 344 The version of the Wordlist MUST be unique within a language code. 346 [[ Note: Requirements to a "smart" composition of the version number 347 are for further study ]] 349 e.g. b.1.2 351 4.2.6. Registration Document(s) () 353 Reference(s) to the Document(s) containing the Wordlist 355 e.g. 356 357 359 e.g. 360 (obsoleted by RFC 9999) 361 362 364 e.g. 365 [International Telecommunications Union, 366 "Wordlist for Foobar application", 367 ITU-F Recommendation B.193, Release 73, Mar 2009.] 368 370 4.2.7. Requesters () 372 The persons requesting the registration of the Wordlist. Usually 373 these are the authors of the Wordlist. 375 e.g. 376 377 379 380 381 John Doe 382 Example Inc. 383 mailto:john.doe@example.com 384 2018-06-20 385 386 388 Note: If there is more than one requester, there must be one 389 element per requester in the element, and one 390 chunk per requester in the element. 392 4.2.8. Further Information () 394 Any other information the authors deem interesting. 396 e.g. 397 more info goes here 398 400 Note: If there is no such additional information, then the 401 element is omitted. 403 4.2.9. Wordlist () 405 The full Wordlist to be registered. The number of words MUST be a 406 power of 2 as specified above. The element names serve as key used 407 for enumeration of the Trustwords (starting at 0) and the elements 408 contains the values being individual natural language words in the 409 respective language. 411 e.g. 412 first 413 second 414 [...] 415 last 416 418 ] ]> 420 [[ Note: The exact representation of the Wordlist is for further 421 study. ]] 423 5. Security Considerations 425 There are no special security considerations. 427 6. Acknowledgements 429 The authors would like to thank the following people who have 430 provided feedback or significant contributions to the development of 431 this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore, 432 Michael Richardson, Rich Salz, and Yoav Nir. 434 This work was initially created by pEp Foundation, and then reviewed 435 and extended with funding by the Internet Society's Beyond the Net 436 Programme on standardizing pEp. [ISOC.bnet] 438 7. References 440 7.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 448 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 449 . 451 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 452 Writing an IANA Considerations Section in RFCs", BCP 26, 453 RFC 8126, DOI 10.17487/RFC8126, June 2017, 454 . 456 7.2. Informative References 458 [E-D.birk-pep-handshake] 459 Marques, H., "pretty Easy privacy (pEp): Contact 460 Authentication through Handshake", June 2018, 461 . 465 Early draft 467 [E-D.birk-pep-keysync] 468 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key 469 Synchronization Protocol", June 2018, 470 . 474 Early draft 476 [I-D.birk-pep] 477 Birk, V., Marques, H., Shelburn, S., and S. Koechli, 478 "pretty Easy privacy (pEp): Privacy by Default", draft- 479 birk-pep-01 (work in progress), January 2018. 481 [ISO693] "Language codes - ISO 639", n.d., 482 . 484 [ISOC.bnet] 485 Simao, I., "Beyond the Net. 12 Innovative Projects 486 Selected for Beyond the Net Funding. Implementing Privacy 487 via Mass Encryption: Standardizing pretty Easy privacy's 488 protocols", June 2017, . 492 [PGP.wl] "PGP word list", November 2017, 493 . 496 [RFC1751] McDonald, D., "A Convention for Human-Readable 128-bit 497 Keys", RFC 1751, DOI 10.17487/RFC1751, December 1994, 498 . 500 [RFC1760] Haller, N., "The S/KEY One-Time Password System", 501 RFC 1760, DOI 10.17487/RFC1760, February 1995, 502 . 504 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 505 Time Password System", STD 61, RFC 2289, 506 DOI 10.17487/RFC2289, February 1998, 507 . 509 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 510 Wu, "Internet X.509 Public Key Infrastructure Certificate 511 Policy and Certification Practices Framework", RFC 3647, 512 DOI 10.17487/RFC3647, November 2003, 513 . 515 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 516 Registration of Enumservices: Guide, Template, and IANA 517 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 518 2011, . 520 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 521 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 522 March 2011, . 524 Appendix A. IANA XML Template Example 526 This section contains a non-normative example of the IANA 527 Registration Template XML chunk. 529 530 lat 531 16 532 57337 533 no 534 n.0.1 535 536 537 538 539 540 541 542 543 This Wordlist has been optimized for 544 the Roman Standards Process. 545 546 547 548 errare 549 humanum 550 [...] 551 est 552 553 555 556 557 Julius Caesar 558 Curia Romana 559 mailto:julius.cesar@example.com 560 1999-12-31 561 562 564 Appendix B. Document Changelog 566 [[ RFC Editor: This section is to be removed before publication ]] 568 o draft-birk-pep-trustwords-02: 570 * Minor editorial changes and bug fixes 572 * Added more items to Open Issues 574 * Add usage example 576 o draft-birk-pep-trustwords-01: 578 * Included feedback from mailing list and IETF-101 SECDISPATCH 579 WG, e.g. 581 + Added more explanatory text / less focused on the main use 582 case 584 + Bit size as parameter 586 * Explicitly stated translations are out-of-scope for this 587 document 589 * Added draft IANA XML Registration template, considerations, 590 explanation and examples 592 * Added Changelog to Appendix 594 * Added Open Issue section to Appendix 596 Appendix C. Open Issues 598 [[ RFC Editor: This section should be empty and is to be removed 599 before publication ]] 601 o More explanatory text for Trustword use cases, properties and 602 requirements 604 o Further details of the IANA registry and requirements for the 605 expert to assess the specification 607 o Decide which ISO language code either 639-1 or 639-3 to use, i.e., 608 ISO-639-1 (e.g., ca, de, en, ...) as currently used in pEp 609 implementations (running code) or ISO-693-3 (eng, deu, ita, ...) 611 o Adjust exact representation of wordlists 612 * e.g. XML, CSV, ... 614 * Syntax for non-ASCII letters or language symbols (UTF-8) in 615 Wordlists 617 o Need for optional entropy value assigned to words, to account for 618 similar phonetics among words in the same wordlist? 620 o Need for an additional field, to define what a wordlist is 621 optimized for, e.g., "entropy", "minimize word lengths", ...? 623 o Work out (requirements for) "smart" composition of the version 624 number 626 o Decide whether in non-bijective Wordlists the redundant words need 627 to be repeated in the IANA Registration 629 o Register only a hash over the wordlist with IANA? 631 o Does it make sense to open registrations for other patterns than 632 just words, e.g., images? 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/ 653 Bernie Hoeneisen 654 Ucom Standards Track Solutions GmbH 655 CH-8046 Zuerich 656 Switzerland 658 Phone: +41 44 500 52 44 659 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 660 URI: https://ucom.ch/