idnits 2.17.1 draft-marques-pep-handshake-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 (July 08, 2020) is 1389 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) == Outdated reference: A later version (-06) exists of draft-birk-pep-05 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: A later version (-03) exists of draft-pep-keysync-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Marques 3 Internet-Draft B. Hoeneisen 4 Intended status: Standards Track pEp Foundation 5 Expires: January 9, 2021 July 08, 2020 7 pretty Easy privacy (pEp): Contact and Channel Authentication through 8 Handshake 9 draft-marques-pep-handshake-05 11 Abstract 13 In interpersonal messaging, end-to-end encryption means for public 14 key distribution and verification of its authenticity are needed; the 15 latter to prevent man-in-the-middle (MITM) attacks. 17 This document proposes a new method to easily verify a public key is 18 authentic by a Handshake process that allows users to easily 19 authenticate their communication channel. The new method is targeted 20 to Opportunistic Security scenarios and is already implemented in 21 several applications of pretty Easy privacy (pEp). 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, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Existing Solutions . . . . . . . . . . . . . . . . . . . 4 63 3. The pEp Handshake Proposal . . . . . . . . . . . . . . . . . 5 64 3.1. Verification Process . . . . . . . . . . . . . . . . . . 6 65 3.1.1. Short, Long and Full Trustword Mapping . . . . . . . 7 66 3.1.2. Display Modes . . . . . . . . . . . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 72 7.2. Current software implementing pEp . . . . . . . . . . . . 9 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 9.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 12 78 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 In interpersonal messaging end-to-end encryption means for public key 84 distribution and verification of its authenticity are needed. 86 Examples for key distribution include: 88 o Exchange public keys out-of-band before encrypted communication 90 o Use of centralized public key stores (e.g., OpenPGP Key Servers) 92 o Ship public keys in-band when communicating 94 To prevent man-in-the-middle (MITM) attacks, additionally the 95 authenticity of a public key needs to be verified. Methods to 96 authenticate public keys of peers include, e.g., to verify digital 97 signatures of public keys (which may be signed in a hierarchical or 98 flat manner, e.g., by a Web of Trust (WoT)), to compare the public 99 key's fingerprints via a suitable independent channel, or to scan a 100 QR mapping of the fingerprint (cf. Section 2). 102 This document proposes a new method to verify the authenticity of 103 public keys by a Handshake process that allows users to easily verify 104 their communication channel. Fingerprints of the involved peers are 105 combined and mapped to (common) Trustwords [I-D.birk-pep-trustwords]. 106 The successful manual comparison of these Trustwords is used to 107 consider the communication channel as trusted. 109 The proposed method is already implemented and used in applications 110 of pretty Easy privacy (pEp) [I-D.birk-pep]. This document is 111 targeted to applications based on the pEp framework and Opportunistic 112 Security [RFC7435]. However, it may be also used in other 113 applications as suitable. 115 Note: The pEp framework [I-D.birk-pep] proposes to automatize the use 116 of end-to-end encryption for Internet users of email and other 117 messaging applications and introduces methods to easily allow 118 authentication. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 1.2. Terms 128 The following terms are defined for the scope of this document: 130 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 131 to 65535) to natural language words. When doing a Handshake, 132 peers are shown combined Trustwords of both public keys involved 133 to ease the comparison. [I-D.birk-pep-trustwords] 135 o Trust On First Use (TOFU): cf. [RFC7435], which states: "In a 136 protocol, TOFU calls for accepting and storing a public key or 137 credential associated with an asserted identity, without 138 authenticating that assertion. Subsequent communication that is 139 authenticated using the cached key or credential is secure against 140 an MiTM attack, if such an attack did not succeed during the 141 vulnerable initial communication." 143 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 144 form of active wiretapping attack in which the attacker intercepts 145 and selectively modifies communicated data to masquerade as one or 146 more of the entities involved in a communication association." 148 2. Problem Statement 150 To secure a communication channel, in public key cryptography each 151 involved peer needs a key pair. Its public key needs to be shared to 152 other peers by some means. However, the key obtained by the receiver 153 may have been substituted or tampered with to allow for re-encryption 154 attacks. To prevent such man-in-the-middle (MITM) attacks, an 155 important step is to verify the authenticity of a public key 156 obtained. 158 2.1. Use Cases 160 Such a verification process is useful in at least two scenarios: 162 o Verify channels to peers, e.g., to make sure opportunistically 163 exchanged keys for end-to-end encryption are authentic. 165 o Verify channels between own devices (in multi-device contexts), 166 e.g., for the purpose of importing and synchronizing keys among 167 different devices belonging to the same user (cf. 168 [I-D.pep-keysync]). This scenario is comparable to Bluetooth 169 pairing before starting data transfers. 171 2.2. Existing Solutions 173 Current methods to authenticate public keys of peers include: 175 o Digitally signed public keys are verified by a chain of trust. 176 Two trust models are common in today's implementations. 178 * Signing is carried out hierarchically, e.g. in a Public Key 179 Infrastructure (PKI) [RFC5280], in which case the verification 180 is based on a chain of trust with a Trust Anchor (TA) at the 181 root. 183 * Signing of public keys is done in a flat manner (by a Web of 184 Trust), e.g., key signing in OpenPGP [RFC4880], where users 185 sign the public keys of other users. Verification may be based 186 on transitive trust. 188 o Peers are expected to directly compare the public key's 189 fingerprints by any suitable independent channel - e.g, by phone 190 or with a face-to-face meeting. This method is often used in 191 OpenPGP [RFC4880] contexts. 193 o The public keys' fingerprints are mapped into a QR code, which is 194 expected to be scanned between the peers when they happen to meet 195 face-to-face. This method is, e.g., used in the chat application 196 Threema [threema]. 198 o The public keys' fingerprints are mapped into numerical codes 199 which decimal digits only (so-called "safety numbers"), which 200 makes the strings the humans need to compare easier in respect to 201 hexadecimal numbers, but longer and thus nevertheless cumbersome. 202 This method is, e.g., used in the chat application Signal 203 [signal]. 205 Some of the methods can even be used in conjunction with Trustwords 206 [I-D.birk-pep-trustwords] or the PGP Word list [PGP.wl]. 208 None of the existing solutions meets all requirements set up by pEp 209 [I-D.birk-pep], e.g.: 211 o Easy solution that can be handled easily by ordinary users 213 o In case privacy and security contradict each other, privacy is 214 always preferred over security (e.g., the Web of Trust contradicts 215 privacy) 217 o No central entities 219 Most of today's systems lack easy ways for users to authenticate 220 their communication channel. Some methods leak private data (e.g., 221 their social graph) or depend on central entities. Thus, none of 222 today's systems fulfills all of the pEp requirements (cf. above). 224 3. The pEp Handshake Proposal 226 In pretty Easy privacy (pEp), the proposed approach for peers to 227 authenticate each other is to engage in the pEp Handshake. 229 In current pEp implementations (cf. Section 7.2), the same kinds of 230 keys as in OpenPGP are used. Such keys include a fingerprint as 231 cryptographic hash over the public key. This fingerprint is normally 232 represented in a hexadecimal form, consisting of ten 4-digit 233 hexadecimal blocks, e.g.: 235 8E31 EF52 1D47 5183 3E9D EADC 0FFE E7A5 7E5B AD19 237 Each block may also be represented in decimal numbers from 0 to 65535 238 or in other numerical forms, e.g. 240 o Hexadecimal: 8E31 242 o Decimal: 36401 244 o Binary: 1000111000110001 246 3.1. Verification Process 248 In the pEp Handshake the fingerprints of any two peers involved are 249 combined and displayed in form of Trustwords 250 [I-D.birk-pep-trustwords] for easy comparison by the involved 251 parties. 253 The default verification process involves three steps: 255 1. Combining fingerprints by XOR function 257 Any two peers' fingerprints are combined bit-by-bit using the 258 Exclusive-OR (XOR) function resulting in the Combined Fingerprint 259 (CFP). 261 2. Mapping result to Trustwords: 263 The CFP is then mapped to 16-bit Trustwords (i.e., every 4-digit 264 hexadecimal block is mapped to a given Trustword) resulting in 265 the Trustword Mapping (TWM). 267 3. Verify Trustwords over independent channel 269 The resulting Trustwords (TWM) are compared and verified over an 270 independent channel, e.g., a phone line. If this step was 271 successful, the channel can be marked as authenticated. 273 Note: In prior implementations of pEp the fingerprints of any two 274 peers were concatenated. While this has the advantage that the own 275 identity's Trustwords can be printed on a business card (like with 276 fingerprints) or on contact sites or in signature texts of emails, 277 this at the same time has the drawback that users might not carefully 278 compare the words as they start to remember and recognize their 279 Trustwords in the concatenated mapping. The avoid this undesired 280 training effect, Trustwords for any peer-to-peer combination shall 281 (very likely) differ. 283 3.1.1. Short, Long and Full Trustword Mapping 285 The more an ordinary user needs to contribute to a process, the less 286 likely a user will carry out all steps carefully. In particular, it 287 was observed that a simple (manual) comparison of OpenPGP 288 fingerprints is rarely carried out to the full extent, i.e., mostly 289 only parts of the fingerprint are compared, if at all. 291 For usability reasons and to create incentives for people to actually 292 carry out a Handshake (while maintaining an certain level of 293 entropy), pEp allows for different entropy levels, i.e.: 295 1. Full Trustword Mapping (F-TWM) MUST represent the maximum entropy 296 achievable by the mapping. This means all Trustwords of a TWM 297 MUST be displayed and compared. 299 E.g., the fingerprint 301 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 303 is mapped to 305 dog house brother town fat bath school banana kite task 307 2. Long Trustword Mapping (L-TWM) requires a number of Trustwords 308 that MUST retain at least 128 bits of entropy. Thus, L-TWM 309 results into at least eight Trustwords to be compared by the 310 user. 312 E.g., the fingerprint 314 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC [ 3F13 ] 316 is mapped to 318 dog house brother town fat bath school banana kite [ remaining 319 Trustword(s) omitted ] 321 3. Short Trustword Mapping (S-TWM) requires a number of Trustwords 322 that MUST retain at least 64 bits of entropy. Thus, S-TWM 323 results into at least four Trustwords to be compared by the user. 325 E.g., the fingerprint 327 F482 E952 2F48 618B 01BC [ 31DC 5428 D7FA ACDC 3F13 ] 329 is mapped to 330 dog house brother town fat [ remaining Trustwords omitted ] 332 3.1.2. Display Modes 334 The pEp Handshake has three display modes for the verification 335 process. All of the following modes MUST be implemented: 337 1. S-TWM mode (default) 339 By default the S-TWM SHOULD be displayed to the user for 340 comparison and verification. An easy way to switch to L-TWM mode 341 MUST be implemented. An easy way to switch to fingerprint mode 342 (see below) SHOULD be implemented. An easy way to switch to 343 F-TWM mode MAY be implemented 345 2. L-TWM mode 347 There are situations, where S-TWM is not sufficient (e.g., 348 communication parties that are more likely under attack), in 349 which the L-TWM MAY be displayed to the user by default. An easy 350 way to switch to F-TWM mode MUST be implemented. An easy way to 351 switch to fingerprint mode (see below) SHOULD be implemented. An 352 easy way to switch to S-TWM mode MAY be implemented 354 3. F-TWM mode 356 The full F-TWM MUST be implemented too, to address high risk 357 scenarios. An easy way to switch to fingerprint mode (see below) 358 SHOULD be implemented. Easy ways to switch to L-TWM or S-TWM 359 mode MAY be implemented. 361 4. Fingerprint mode (fallback) 363 To retain compatibility to existing OpenPGP users (that know 364 nothing about Trustwords), the fingerprint mode, a fallback to 365 compare the original fingerprints (usually in hexadecimal form) 366 MAY be used. An easy way to switch to a least one of the TWM 367 modes MUST be implemented. 369 If the verification process was successful, the user confirms it, 370 e.g. by setting a check mark. Once the user has confirmed it, the 371 Privacy Status [I-D.marques-pep-rating] for this channel MUST be 372 updated accordingly. 374 4. Security Considerations 376 A (global) adversary can pre-generate all Trustwords any two users 377 expect to compare and try to engage in MITM attacks which fit - it 378 MUST NOT be assumed public keys and thus fingerprints to be something 379 to stay secret, especially as in pEp public keys are aggressively 380 distributed to all peers. Also similar Trustwords can be generated, 381 which spelled on the phone might sound very similar. 383 5. Privacy Considerations 385 [[ TODO ]] 387 6. IANA Considerations 389 This document has no actions for IANA. 391 7. Implementation Status 393 7.1. Introduction 395 This section records the status of known implementations of the 396 protocol defined by this specification at the time of posting of this 397 Internet-Draft, and is based on a proposal described in [RFC7942]. 398 The description of implementations in this section is intended to 399 assist the IETF in its decision processes in progressing drafts to 400 RFCs. Please note that the listing of any individual implementation 401 here does not imply endorsement by the IETF. Furthermore, no effort 402 has been spent to verify the information presented here that was 403 supplied by IETF contributors. This is not intended as, and must not 404 be construed to be, a catalog of available implementations or their 405 features. Readers are advised to note that other implementations may 406 exist. 408 According to [RFC7942], "[...] this will allow reviewers and working 409 groups to assign due consideration to documents that have the benefit 410 of running code, which may serve as evidence of valuable 411 experimentation and feedback that have made the implemented protocols 412 more mature. It is up to the individual working groups to use this 413 information as they see fit." 415 7.2. Current software implementing pEp 417 The following software implementing the pEp protocols (to varying 418 degrees) already exists: 420 o pEp for Outlook as add-on for Microsoft Outlook, release 421 [SRC.pepforoutlook] 423 o pEp for iOS (implemented in a new MUA), release [SRC.pepforios] 425 o pEp for Android (based on a fork of the K9 MUA), release 426 [SRC.pepforandroid] 428 o pEp for Thunderbird as a new add-on for Thunderbird, beta 429 [SRC.pepforthunderbird] 431 o Enigmail/pEp as add-on for Mozilla Thunderbird, release (will be 432 discontinued early 2021) [SRC.enigmailpep] 434 pEp for Android, iOS, Outlook and Thunderbird are provided by pEp 435 Security, a commercial entity specializing in end-user software 436 implementing pEp while Enigmail/pEp is pursued as community project, 437 supported by the pEp Foundation. 439 All software is available as Free Software and published also in 440 source form. 442 Handshake is already implemented in all platforms listed above. 444 8. Acknowledgments 446 Special thanks to Volker Birk and Leon Schumacher who developed the 447 original concept of the pEp Handshake. 449 This work was initially created by pEp Foundation, and then reviewed 450 and extended with funding by the Internet Society's Beyond the Net 451 Programme on standardizing pEp. [ISOC.bnet] 453 9. References 455 9.1. Normative References 457 [I-D.birk-pep] 458 Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy 459 privacy (pEp): Privacy by Default", draft-birk-pep-05 460 (work in progress), November 2019. 462 [I-D.birk-pep-trustwords] 463 Hoeneisen, B. and H. Marques, "IANA Registration of 464 Trustword Lists: Guide, Template and IANA Considerations", 465 draft-birk-pep-trustwords-05 (work in progress), January 466 2020. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 474 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 475 . 477 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 478 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 479 December 2014, . 481 9.2. Informative References 483 [I-D.marques-pep-rating] 484 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 485 Mapping of Privacy Rating", draft-marques-pep-rating-03 486 (work in progress), January 2020. 488 [I-D.pep-keysync] 489 Birk, V., Hoeneisen, B., and K. Bristol, "pretty Easy 490 privacy (pEp): Key Synchronization Protocol (KeySync)", 491 draft-pep-keysync-00 (work in progress), November 2019. 493 [ISOC.bnet] 494 Simao, I., "Beyond the Net. 12 Innovative Projects 495 Selected for Beyond the Net Funding. Implementing Privacy 496 via Mass Encryption: Standardizing pretty Easy privacy's 497 protocols", June 2017, . 501 [PGP.wl] "PGP word list", November 2017, 502 . 505 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 506 Thayer, "OpenPGP Message Format", RFC 4880, 507 DOI 10.17487/RFC4880, November 2007, 508 . 510 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 511 Housley, R., and W. Polk, "Internet X.509 Public Key 512 Infrastructure Certificate and Certificate Revocation List 513 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 514 . 516 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 517 Code: The Implementation Status Section", BCP 205, 518 RFC 7942, DOI 10.17487/RFC7942, July 2016, 519 . 521 [signal] "Signal", n.d., . 523 [SRC.enigmailpep] 524 "Source code for Enigmail/pEp", July 2020, 525 . 527 [SRC.pepforandroid] 528 "Source code for pEp for Android", July 2020, 529 . 531 [SRC.pepforios] 532 "Source code for pEp for iOS", July 2020, 533 . 535 [SRC.pepforoutlook] 536 "Source code for pEp for Outlook", July 2020, 537 . 539 [SRC.pepforthunderbird] 540 "Source code for pEp for Thunderbird", July 2020, 541 . 543 [threema] "Threema - Seriously secure messaging", n.d., 544 . 546 Appendix A. Document Changelog 548 [[ RFC Editor: This section is to be removed before publication ]] 550 o draft-marques-pep-handshake-05: 552 * Typos and update references 554 o draft-marques-pep-handshake-04: 556 * Updated terms and references 558 o draft-marques-pep-handshake-03: 560 * Updated terms and references 562 o draft-marques-pep-handshake-02: 564 * Update Sections "Display modes" and "Short, Long and Full 565 Trustword Mapping" 567 * Add Privacy and IANA Considerations sections 569 * Minor editorial changes 571 o draft-marques-pep-handshake-01: 573 * Fix references 575 * Rewrite Sections "Display modes" and "Short, Long and Full 576 Trustword Mapping" 578 * Add reason why not to concatenate and map fingerprints instead 580 * Minor editorial changes 582 o draft-marques-pep-handshake-00: 584 * Initial version 586 Appendix B. Open Issues 588 [[ RFC Editor: This section should be empty and is to be removed 589 before publication ]] 591 o Add description for further processes to change the trust level, 592 e.g., to remove trust or even mistrust a peer and alike. 594 Authors' Addresses 596 Hernani Marques 597 pEp Foundation 598 Oberer Graben 4 599 CH-8400 Winterthur 600 Switzerland 602 Email: hernani.marques@pep.foundation 603 URI: https://pep.foundation/ 604 Bernie Hoeneisen 605 pEp Foundation 606 Oberer Graben 4 607 CH-8400 Winterthur 608 Switzerland 610 Email: bernie.hoeneisen@pep.foundation 611 URI: https://pep.foundation/