idnits 2.17.1 draft-marques-pep-handshake-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 (July 07, 2019) is 1752 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-03 == Outdated reference: A later version (-05) exists of draft-birk-pep-trustwords-03 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: A later version (-01) exists of draft-hoeneisen-pep-keysync-00 == Outdated reference: A later version (-03) exists of draft-marques-pep-rating-01 Summary: 2 errors (**), 0 flaws (~~), 5 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 pEp Foundation 4 Intended status: Standards Track B. Hoeneisen 5 Expires: January 8, 2020 Ucom.ch 6 July 07, 2019 8 pretty Easy privacy (pEp): Contact and Channel Authentication through 9 Handshake 10 draft-marques-pep-handshake-03 12 Abstract 14 In interpersonal messaging end-to-end encryption means for public key 15 distribution and verification of its authenticity are needed; the 16 latter to prevent man-in-the-middle (MITM) attacks. 18 This document proposes a new method to easily verify a public key is 19 authentic by a Handshake process that allows users to easily 20 authenticate their communication channel. The new method is targeted 21 to Opportunistic Security scenarios and is already implemented in 22 several applications of pretty Easy privacy (pEp). 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 January 8, 2020. 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Existing Solutions . . . . . . . . . . . . . . . . . . . 4 64 3. The pEp Handshake Proposal . . . . . . . . . . . . . . . . . 5 65 3.1. Verification Process . . . . . . . . . . . . . . . . . . 6 66 3.1.1. Short, Long and Full Trustword Mapping . . . . . . . 6 67 3.1.2. Display Modes . . . . . . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 72 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 73 7.2. Current software implementing pEp . . . . . . . . . . . . 9 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 12 79 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 In interpersonal messaging end-to-end encryption means for public key 85 distribution and verification of its authenticity are needed. 87 Examples for key distribution include: 89 o Exchange public keys out-of-band before encrypted communication 91 o Use of centralized public key stores (e.g., OpenPGP Key Servers) 93 o Ship public keys in-band when communicating 95 To prevent man-in-the-middle (MITM) attacks, additionally the 96 authenticity of a public key needs to be verified. Methods to 97 authenticate public keys of peers include, e.g., to verify digital 98 signatures of public keys (which may be signed in a hierarchical or 99 flat manner, e.g., by a Web of Trust (WoT)), to compare the public 100 key's fingerprints via a suitable independent channel, or to scan a 101 QR mapping of the fingerprint (cf. Section 2). 103 This document proposes a new method to verify the authenticity of 104 public keys by a Handshake process that allows users to easily verify 105 their communication channel. Fingerprints of the involved peers are 106 combined and mapped to (common) Trustwords [I-D.birk-pep-trustwords]. 107 The successful manual comparison of these Trustwords is used to 108 consider the communication channel as trusted. 110 The proposed method is already implemented and used in applications 111 of pretty Easy privacy (pEp) [I-D.birk-pep]. This document is 112 targeted to applications based on the pEp framework and Opportunistic 113 Security [RFC7435]. However, it may be also used in other 114 applications as suitable. 116 Note: The pEp framework [I-D.birk-pep] proposes to automatize the use 117 of end-to-end encryption for Internet users of email and other 118 messaging applications and introduces methods to easily allow 119 authentication. 121 1.1. Requirements Language 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 1.2. Terms 129 The following terms are defined for the scope of this document: 131 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 132 to 65535) to natural language words. When doing a Handshake, 133 peers are shown combined Trustwords of both public keys involved 134 to ease the comparison. [I-D.birk-pep-trustwords] 136 o Trust On First Use (TOFU): cf. [RFC7435], which states: "In a 137 protocol, TOFU calls for accepting and storing a public key or 138 credential associated with an asserted identity, without 139 authenticating that assertion. Subsequent communication that is 140 authenticated using the cached key or credential is secure against 141 an MiTM attack, if such an attack did not succeed during the 142 vulnerable initial communication." 144 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 145 form of active wiretapping attack in which the attacker intercepts 146 and selectively modifies communicated data to masquerade as one or 147 more of the entities involved in a communication association." 149 2. Problem Statement 151 To secure a communication channel, in public key cryptography each 152 involved peer needs a key pair. Its public key needs to be shared to 153 other peers by some means. However, the key obtained by the receiver 154 may have been substituted or tampered with to allow for re-encryption 155 attacks. To prevent such man-in-the-middle (MITM) attacks, an 156 important step is to verify the authenticity of a public key 157 obtained. 159 2.1. Use Cases 161 Such a verification process is useful in at least two scenarios: 163 o Verify channels to peers, e.g., to make sure opportunistically 164 exchanged keys for end-to-end encryption are authentic. 166 o Verify channels between own devices (in multi-device contexts), 167 e.g., for the purpose of importing and synchronizing keys among 168 different devices belonging to the same user (cf. 169 [I-D.hoeneisen-pep-keysync]). This scenario is comparable to 170 Bluetooth pairing before starting data transfers. 172 2.2. Existing Solutions 174 Current methods to authenticate public keys of peers include: 176 o Digitally signed public keys are verified by a chain of trust. 177 Two trust models are common in today's implementations. 179 * Signing is carried out hierarchically, e.g. in a Public Key 180 Infrastructure (PKI) [RFC5280], in which case the verification 181 is based on a chain of trust with a Trust Anchor (TA) at the 182 root. 184 * Signing of public keys is done in a flat manner (by a Web of 185 Trust), e.g., key signing in OpenPGP [RFC4880], where users 186 sign the public keys of other users. Verification may be based 187 on transitive trust. 189 o Peers are expected to directly compare the public key's 190 fingerprints by any suitable independent channel - e.g, by phone 191 or with a face-to-face meeting. This method is often used in 192 OpenPGP [RFC4880] contexts. 194 o The public keys' fingerprints are mapped into a QR code, which is 195 expected to be scanned between the peers when they happen to meet 196 face-to-face. This method is, e.g., used in the chat application 197 Threema [threema]. 199 o The public keys' fingerprints are mapped into numerical codes 200 which decimal digits only (so-called "safety numbers"), which 201 makes the strings the humans need to compare easier in respect to 202 hexacodes, but longer and thus nevertheless cumbersome. This 203 method is e.g. used in the chat application Signal [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 331 dog house brother town fat [ remaining Trustwords omitted ] 333 3.1.2. Display Modes 335 The pEp Handshake has three display modes for the verification 336 process. All of the following modes MUST be implemented: 338 1. S-TWM mode (default) 340 By default the S-TWM SHOULD be displayed to the user for 341 comparison and verification. An easy way to switch to L-TWM mode 342 MUST be implemented. An easy way to switch to fingerprint mode 343 (see below) SHOULD be implemented. An easy way to switch to 344 F-TWM mode MAY be implemented 346 2. L-TWM mode 348 There are situations, where S-TWM is not sufficient (e.g., 349 communication parties that are more likely under attack), in 350 which the L-TWM MAY be displayed to the user by default. An easy 351 way to switch to F-TWM mode MUST be implemented. An easy way to 352 switch to fingerprint mode (see below) SHOULD be implemented. An 353 easy way to switch to S-TWM mode MAY be implemented 355 3. F-TWM mode 357 The full F-TWM MUST be implemented too, to address high risk 358 secenarios. An easy way to switch to fingerprint mode (see 359 below) SHOULD be implemented. Easy ways to switch to L-TWM or 360 S-TWM mode MAY be implemented. 362 4. Fingerprint mode (fallback) 364 To retain compatibility to existing OpenPGP users (that know 365 nothing about Trustwords), the fingerprint mode, a fallback to 366 compare the original fingerprints (usually in hexadecimal form) 367 MAY be used. An easy way to switch to a least one of the TWM 368 modes MUST be implemented. 370 If the verification process was successful, the user confirms it, 371 e.g. by setting a check mark. Once the user has confirmed it, the 372 Privacy Status [I-D.marques-pep-rating] for this channel MUST be 373 updated accordingly. 375 4. Security Considerations 377 A (global) adversary can pre-generate all Trustwords any two users 378 expect to compare and try to engage in MITM attacks which fit - it 379 MUST NOT be assumed public keys and thus fingerprints to be something 380 to stay secret, especially as in pEp public keys are aggressively 381 distributed to all peers. Also similar Trustwords can be generated, 382 which spelled on the phone might sound very similar. 384 5. Privacy Considerations 386 [[ TODO ]] 388 6. IANA Considerations 390 This document has no actions for IANA. 392 7. Implementation Status 394 7.1. Introduction 396 This section records the status of known implementations of the 397 protocol defined by this specification at the time of posting of this 398 Internet-Draft, and is based on a proposal described in [RFC7942]. 399 The description of implementations in this section is intended to 400 assist the IETF in its decision processes in progressing drafts to 401 RFCs. Please note that the listing of any individual implementation 402 here does not imply endorsement by the IETF. Furthermore, no effort 403 has been spent to verify the information presented here that was 404 supplied by IETF contributors. This is not intended as, and must not 405 be construed to be, a catalog of available implementations or their 406 features. Readers are advised to note that other implementations may 407 exist. 409 According to [RFC7942], "[...] this will allow reviewers and working 410 groups to assign due consideration to documents that have the benefit 411 of running code, which may serve as evidence of valuable 412 experimentation and feedback that have made the implemented protocols 413 more mature. It is up to the individual working groups to use this 414 information as they see fit." 416 7.2. Current software implementing pEp 418 The following software implementing the pEp protocols (to varying 419 degrees) already exists: 421 o pEp for Outlook as add-on for Microsoft Outlook, release 422 [SRC.pepforoutlook] 424 o pEp for Android (based on a fork of the K9 MUA), release 425 [SRC.pepforandroid] 427 o Enigmail/pEp as add-on for Mozilla Thunderbird, release 428 [SRC.enigmailpep] 430 o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios] 432 pEp for Android, iOS and Outlook are provided by pEp Security, a 433 commercial entity specializing in end-user software implementing pEp 434 while Enigmail/pEp is pursued as community project, supported by the 435 pEp Foundation. 437 All software is available as Free Software and published also in 438 source form. 440 Handshake is already implemented in all platforms listed above. 442 8. Acknowledgements 444 Special thanks to Volker Birk and Leon Schumacher who developed the 445 original concept of the pEp Handshake. 447 This work was initially created by pEp Foundation, and then reviewed 448 and extended with funding by the Internet Society's Beyond the Net 449 Programme on standardizing pEp. [ISOC.bnet] 451 9. References 453 9.1. Normative References 455 [I-D.birk-pep] 456 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 457 Privacy by Default", draft-birk-pep-03 (work in progress), 458 March 2019. 460 [I-D.birk-pep-trustwords] 461 Birk, V., Marques, H., and B. Hoeneisen, "IANA 462 Registration of Trustword Lists: Guide, Template and IANA 463 Considerations", draft-birk-pep-trustwords-03 (work in 464 progress), March 2019. 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 472 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 473 . 475 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 476 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 477 December 2014, . 479 9.2. Informative References 481 [I-D.hoeneisen-pep-keysync] 482 Hoeneisen, B. and H. Marques, "pretty Easy privacy (pEp): 483 Key Synchronization Protocol", draft-hoeneisen-pep- 484 keysync-00 (work in progress), July 2019. 486 [I-D.marques-pep-rating] 487 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 488 Mapping of Privacy Rating", draft-marques-pep-rating-01 489 (work in progress), March 2019. 491 [ISOC.bnet] 492 Simao, I., "Beyond the Net. 12 Innovative Projects 493 Selected for Beyond the Net Funding. Implementing Privacy 494 via Mass Encryption: Standardizing pretty Easy privacy's 495 protocols", June 2017, . 499 [PGP.wl] "PGP word list", November 2017, 500 . 503 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 504 Thayer, "OpenPGP Message Format", RFC 4880, 505 DOI 10.17487/RFC4880, November 2007, 506 . 508 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 509 Housley, R., and W. Polk, "Internet X.509 Public Key 510 Infrastructure Certificate and Certificate Revocation List 511 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 512 . 514 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 515 Code: The Implementation Status Section", BCP 205, 516 RFC 7942, DOI 10.17487/RFC7942, July 2016, 517 . 519 [signal] "Signal", n.d., . 521 [SRC.enigmailpep] 522 "Source code for Enigmail/pEp", July 2019, 523 . 525 [SRC.pepforandroid] 526 "Source code for pEp for Android", July 2019, 527 . 529 [SRC.pepforios] 530 "Source code for pEp for iOS", July 2019, 531 . 533 [SRC.pepforoutlook] 534 "Source code for pEp for Outlook", July 2019, 535 . 537 [threema] "Threema - Seriously secure messaging", n.d., 538 . 540 Appendix A. Document Changelog 542 [[ RFC Editor: This section is to be removed before publication ]] 544 o draft-marques-pep-handshake-03: 546 * Updated Terms and References 548 o draft-marques-pep-handshake-02: 550 * Update Sections "Display modes" and "Short, Long and Full 551 Trustword Mapping" 553 * Add Privacy and IANA Considerations sections 555 * Minor editorial changes 557 o draft-marques-pep-handshake-01: 559 * Fix references 561 * Rewrite Sections "Display modes" and "Short, Long and Full 562 Trustword Mapping" 564 * Add reason why not to concatenate and map fingerprints instead 566 * Minor editorial changes 568 o draft-marques-pep-handshake-00: 570 * Initial version 572 Appendix B. Open Issues 574 [[ RFC Editor: This section should be empty and is to be removed 575 before publication ]] 577 o Add description for further processes to change the trust level, 578 e.g., to remove trust or even mistrust a peer and alike. 580 Authors' Addresses 582 Hernani Marques 583 pEp Foundation 584 Oberer Graben 4 585 CH-8400 Winterthur 586 Switzerland 588 Email: hernani.marques@pep.foundation 589 URI: https://pep.foundation/ 591 Bernie Hoeneisen 592 Ucom Standards Track Solutions GmbH 593 CH-8046 Zuerich 594 Switzerland 596 Phone: +41 44 500 52 40 597 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 598 URI: https://ucom.ch/