idnits 2.17.1 draft-marques-pep-handshake-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-birk-pep-02 == Outdated reference: A later version (-05) exists of draft-birk-pep-trustwords-02 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 H. Marques 3 Internet-Draft pEp Foundation 4 Intended status: Informational B. Hoeneisen 5 Expires: January 1, 2019 Ucom.ch 6 June 30, 2018 8 pretty Easy privacy (pEp): Contact and Channel Authentication through 9 Handshake 10 draft-marques-pep-handshake-00 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 verify 20 their communication channel. The new method is targeted to 21 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 1, 2019. 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Existing Solutions . . . . . . . . . . . . . . . . . . . 4 63 4. The pEp Handshake Proposal . . . . . . . . . . . . . . . . . 5 64 4.1. Verification Process . . . . . . . . . . . . . . . . . . 5 65 4.1.1. Partial and Full Trustword Mapping . . . . . . . . . 6 66 4.1.2. Display Modes . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. Running Code . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 In interpersonal messaging end-to-end encryption means for public key 81 distribution and verification of its authenticity are needed. 83 Examples for key distribution include: 85 o Exchange keys out-of-band before encrypted communication 87 o Use of centralized public key stores (e.g., OpenPGP Key Servers) 89 o Ship the public key in-band when communicating 91 To prevent man-in-the-middle (MITM) attacks, additionally the 92 authenticity of a public key needs to be verified. Methods to 93 authenticate public keys of peers include, e.g., verify digital 94 signatures of public keys (which may be signed in an hierarchical or 95 flat manner, e.g., by a Web of Trust (WoT)), compare the public key's 96 fingerprints via a suitable independent channel, or scan a QR mapping 97 of the fingerprint (cf. Section 3). 99 This document proposes a new method to verify the authenticity of 100 public keys by a Handshake process that allows users to easily verify 101 their communication channel. Fingerprints of the involved peers are 102 combined and mapped to (common) Trustwords [I-D.birk-pep-trustwords]. 103 The successful manual comparison of the these Trustwords is used to 104 consider the communication channel as trusted. 106 The proposed method is already implemented and used in applications 107 of pretty Easy privacy (pEp) [I-D.birk-pep]. This document is 108 targeted to applications based on the pEp framework and Opportunistic 109 Security [RFC7435]. However, it may be also used in other 110 applications as suitable. 112 2. Terms 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 o Handshake: The process when Alice - e.g. in-person or via phone - 119 contacts Bob to verify Trustwords (or by fallback: fingerprints) 120 is called Handshake. In more detail, this is described in this 121 draft. 123 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 124 to 65535) to natural language words. When doing a Handshake, 125 peers are shown combined Trustwords of both public keys involved 126 to ease the comparison. [I-D.birk-pep-trustwords] 128 o Trust on First Use (TOFU): cf. [RFC7435] 130 o Man-in-the-middle attack (MITM): cf. [RFC4949] 132 3. Problem Statement 134 To secure a communication channel, in public key cryptography the 135 each involved peer needs a key pair. Its public key needs to be 136 shared to other peers by some means. However, the key obtained by 137 the receiver may have been substituted or tampered with to allow for 138 re-encryption attacks. To prevent such man-in-the-middle (MITM) 139 attacks, an important step is to verify the authenticity of a public 140 key obtained. 142 3.1. Use Cases 144 Such a verification process is useful in at least two scenarios: 146 o Verify channels to peers, e.g., to make sure opportunistically 147 exchanged keys for end-to-end encryption are authentic. 149 o Verify channels between own devices (in multi-device contexts), 150 e.g., for the purpose of importing and synchronizing keys among 151 different devices belonging to the same user (cf. 152 [E-D.birk-pep-keysync]). This scenario is comparable to Bluetooth 153 pairing before starting data transfers. 155 3.2. Existing Solutions 157 Current methods to authenticate public keys of peers include: 159 o Digitally signed public keys are verified by a chain of trust. 160 Two trust models are common in today's implementations. 162 * Signing is carried out hierarchically, e.g. in a Public Key 163 Infrastructure (PKI) [RFC5280], in which case the verification 164 is based on a chain of trust with a Trust Anchor (TA) at the 165 root. 167 * Signing of public keys is done in a flat manner (by a Web of 168 Trust), e.g., key signing in OpenPGP [RFC4880], where users 169 sign the public keys of other users. Verification may be based 170 on transitive trust. 172 o Peers are expected to directly compare the public key's 173 fingerprints by any suitable independent channel - e.g, by phone 174 or with a face-to-face meeting. This method is often used in 175 OpenPGP [RFC4880] contexts. 177 o The public keys' fingerprints are mapped into a QR code, which is 178 expected to be scanned between the peers when they happen to meet 179 face-to-face. This method is e.g. used in the chat application 180 Threema [threema]. 182 o The public keys' fingerprints are mapped into numerical codes 183 which decimal digits only, which makes the strings the humans need 184 to compare longer and thus cumbersome. This method is e.g. used 185 in the chat application Signal [signal]. 187 Some of the methods can even be used in conjunction with Trustwords 188 [I-D.birk-pep-trustwords] or the PGP Word list [PGP.wl]. 190 None of the existing solutions meets all requirements set up by pEp 191 [I-D.birk-pep], e.g.: 193 o Easy solution that can be handled easily by ordinary users 195 o In case privacy and security contradict each other, privacy is 196 always preferred over security (e.g., the Web of Trust contradicts 197 privacy) 199 o No central entities 201 Most of today's systems lack easy ways for users to authenticate 202 their communication channel. Some methods leak private data (e.g., 203 their social graph) or depend on central entities. Thus, none of 204 today's systems fulfills all of the pEp requirements (cf. above). 206 4. The pEp Handshake Proposal 208 In pretty Easy privacy (pEp), the proposed approach for peers to 209 authenticate each other is to engage in the pEp Handshake. 211 In current pEp implementations (cf. Section 6.2), the same kinds of 212 keys as in OpenPGP are used. Such keys include a fingerprint as 213 cryptographic hash over the public key. This fingerprint is normally 214 represented in a hexadecimal form, consisting of ten 4-digit 215 hexadecimal blocks, e.g.: 217 8E31 EF52 1D47 5183 3E9D EADC 0FFE E7A5 7E5B AD19 219 Each block may also be represented in decimal numbers from 0 to 65535 220 or in other numerical forms, e.g. 222 o Hexadecimal: 8E31 224 o Decimal: 36401 226 o Binary: 1000111000110001 228 4.1. Verification Process 230 In the pEp Handshake the fingerprints of any two peers involved are 231 combined and displayed in form of Trustwords 232 [I-D.birk-pep-trustwords] for easy comparison by the involved 233 parties. 235 The default verification process involves three steps: 237 1. Combining fingerprints by XOR function 238 Any two peers' fingerprints are combined bit-by-bit using the 239 Exclusive-OR (XOR) function resulting in the Combined Fingerprint 240 (CFP). 242 2. Mapping result to Trustwords: 244 The CFP is then mapped to 16-bit Trustwords (i.e., every 4-digit 245 hexadecimal block is mapped to a given Trustword) resulting in 246 the Trustword Mapping (TWM). 248 3. Verify Trustwords over independent channel 250 The resulting Trustwords (TWM) are compared and verified over an 251 independent channel, e.g., a phone line. If this step was 252 successful, the channel can be marked as authenticated. 254 4.1.1. Partial and Full Trustword Mapping 256 The more an ordinary user needs to contribute to a process, the less 257 likely a user will carry out all steps carefully. In particular, it 258 was observed that a simple (manual) comparison of OpenPGP 259 fingerprints is rarely carried out to the full extent, i.e., mostly 260 only parts of the fingerprint are compared, if at all. 262 For usability reasons and to create incentive for people to actually 263 carry out Handshake (while maintaining an certain level of entropy), 264 pEp allows for different entropy levels, i.e.: 266 1. Full Trustword Mapping (F-TWM) [aka Full Trustwords] MUST 267 represent the maximum entropy achievable by the mapping. This 268 means all Trustwords of a TWM MUST be displayed and compared. 270 e.g. the fingerprint 272 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 274 is mapped to: 276 dog house brother town fat bath school banana kite task 278 2. Partial Trustword Mapping (P-TWM) [aka Short Trustwords] requires 279 a number of Trustwords that MUST retain at least 64-bit of 280 entropy. This means while the first part of the TWM is displayed 281 and compared, the remaining Trustwords are omitted. 283 e.g. the fingerprint 285 F482 E952 2F48 618B 01BC [ 31DC 5428 D7FA ACDC 3F13 ] 287 is mapped to: 289 dog house brother town fat [ remaining Trustwords omitted ] 291 4.1.2. Display Modes 293 The pEp Handshake has three display modes for the verification 294 process. All of the following modes MUST be implemented: 296 1. P-TWM mode (default) 298 By default the P-TWM SHOULD be displayed to the user for 299 comparison and verification. An easy way to switch to F-TWM mode 300 MUST be implemented and an easy way to switch to fingerprint mode 301 SHOULD be implemented. 303 2. F-TWM mode 305 There are situations, where P-TWM is not sufficient (e.g., 306 communication parties that are more likely under attack), in 307 which the F-TWM MAY be displayed to the user by default. An easy 308 way to switch to P-TWM mode MUST be implemented and an easy way 309 to switch to fingerprint mode SHOULD be implemented. 311 3. Fingerprint mode (fallback) 313 To retain compatibility to existing OpenPGP users (that know 314 nothing about Trustwords), the fingerprint mode, a fallback to 315 compare the original fingerprints (usually in hexadecimal form) 316 MAY be used. Easy ways to switch to P-TWM and F-TWM modes SHOULD 317 be implemented. 319 If the verification process was successful, the user confirms it, 320 e.g. by setting a check mark. Once the user has confirmed it, the 321 trust level [E-D.birk-pep-trust-rating] for this channel MUST be 322 updated accordingly. 324 5. Security Considerations 326 A (global) adversary can pre-generate all Trustwords any two users 327 expect to compare and try to engage in MITM attacks which fit - it 328 MUST NOT be assumed public keys and thus fingerprints to be something 329 to stay secret, especially as in pEp public keys are aggressively 330 distributed to all peers. Also similar Trustwords can be generated, 331 which spelled on the phone might sound very similar. 333 6. Implementation Status 335 6.1. Introduction 337 This section records the status of known implementations of the 338 protocol defined by this specification at the time of posting of this 339 Internet-Draft, and is based on a proposal described in [RFC7942]. 340 The description of implementations in this section is intended to 341 assist the IETF in its decision processes in progressing drafts to 342 RFCs. Please note that the listing of any individual implementation 343 here does not imply endorsement by the IETF. Furthermore, no effort 344 has been spent to verify the information presented here that was 345 supplied by IETF contributors. This is not intended as, and must not 346 be construed to be, a catalog of available implementations or their 347 features. Readers are advised to note that other implementations may 348 exist. 350 According to [RFC7942], "[...] this will allow reviewers and working 351 groups to assign due consideration to documents that have the benefit 352 of running code, which may serve as evidence of valuable 353 experimentation and feedback that have made the implemented protocols 354 more mature. It is up to the individual working groups to use this 355 information as they see fit." 357 6.2. Running Code 359 In pEp for email [E-D.birk-pep-email] contexts, Handshakes are 360 already implemented for the following platforms: 362 o Android, in pEp for Android - release [SRC.pepforandroid] 364 o Enigmail, in the Enigmail/pEp mode - release used for new Enigmail 365 users of version 2.0 [SRC.enigmailpep] 367 o iOS, in pEp for iOS - not yet released [SRC.pepforios] 369 o Outlook, in pEp for Outlook - commercial release 370 [SRC.pepforoutlook] 372 In pEp for Outlook also keys from other devices can be imported by 373 the Handshake method. 375 7. Acknowledgements 377 Special thanks to Volker Birk and Leon Schumacher who developed the 378 original concept of the pEp Handshake. 380 This work was initially created by pEp Foundation, and then reviewed 381 and extended with funding by the Internet Society's Beyond the Net 382 Programme on standardizing pEp. [ISOC.bnet] 384 8. References 386 8.1. Normative References 388 [I-D.birk-pep] 389 Birk, V., Marques, H., and S. Shelburn, "pretty Easy 390 privacy (pEp): Privacy by Default", draft-birk-pep-02 391 (work in progress), June 2018. 393 [I-D.birk-pep-trustwords] 394 Birk, V., Marques, H., and B. Hoeneisen, "IANA 395 Registration of Trustword Lists: Guide, Template and IANA 396 Considerations", draft-birk-pep-trustwords-02 (work in 397 progress), June 2018. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 405 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 406 . 408 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 409 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 410 December 2014, . 412 8.2. Informative References 414 [E-D.birk-pep-email] 415 Birk, V. and H. Marques, "pretty Easy privacy (pEp): 416 Secure and Trusted Email Communication", June 2018, 417 . 420 Early draft 422 [E-D.birk-pep-keysync] 423 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key 424 Synchronization Protocol", June 2018, 425 . 429 Early draft 431 [E-D.birk-pep-trust-rating] 432 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Trust 433 Rating System", June 2018, 434 . 437 Early draft 439 [ISOC.bnet] 440 Simao, I., "Beyond the Net. 12 Innovative Projects 441 Selected for Beyond the Net Funding. Implementing Privacy 442 via Mass Encryption: Standardizing pretty Easy privacy's 443 protocols", June 2017, . 447 [PGP.wl] "PGP word list", November 2017, 448 . 451 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 452 Thayer, "OpenPGP Message Format", RFC 4880, 453 DOI 10.17487/RFC4880, November 2007, 454 . 456 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 457 Housley, R., and W. Polk, "Internet X.509 Public Key 458 Infrastructure Certificate and Certificate Revocation List 459 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 460 . 462 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 463 Code: The Implementation Status Section", BCP 205, 464 RFC 7942, DOI 10.17487/RFC7942, July 2016, 465 . 467 [signal] "Signal", n.d., . 469 [SRC.enigmailpep] 470 "Source code for Enigmail/pEp", June 2018, 471 . 473 [SRC.pepforandroid] 474 "Source code for pEp for Android", June 2018, 475 . 477 [SRC.pepforios] 478 "Source code for pEp for iOS", June 2018, 479 . 481 [SRC.pepforoutlook] 482 "Source code for pEp for Outlook", June 2018, 483 . 485 [threema] "Threema - Seriously secure messaging", n.d., 486 . 488 Appendix A. Open Issues 490 [[ RFC Editor: This section should be empty and is to be removed 491 before publication ]] 493 o Add description for further processes to change the trust level, 494 e.g., to remove trust or even mistrust a peer and alike. 496 Authors' Addresses 498 Hernani Marques 499 pEp Foundation 500 Oberer Graben 4 501 CH-8400 Winterthur 502 Switzerland 504 Email: hernani.marques@pep.foundation 505 URI: https://pep.foundation/ 507 Bernie Hoeneisen 508 Ucom Standards Track Solutions GmbH 509 CH-8046 Zuerich 510 Switzerland 512 Phone: +41 44 500 52 44 513 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 514 URI: https://ucom.ch/