idnits 2.17.1 draft-brown-pgp-pfs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 20 instances of lines with control characters in the document. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2440, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates A., but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: INTERNET-DRAFT Zero-Knowledge Systems', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8657 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) ** Obsolete normative reference: RFC 2440 (ref. '1') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 1825 (ref. '2') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 821 (ref. '10') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2246 (ref. '11') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group I. Brown 2 draft-brown-pgp-pfs-00.txt University College London 3 Updates: RFC 2440 A. Back 4 Category: INTERNET-DRAFT Zero-Knowledge Systems 5 Expires: 16 January 2001 B. Laurie 6 A.L. Digital Ltd 7 July 2000 9 Forward Secrecy Extensions for OpenPGP 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright 35 Copyright (C) Internet Society 2000. All rights reserved. 36 Reproduction or translation of the complete document, but not of 37 extracts, including this notice, is freely permitted. 39 Abstract 41 The confidentiality of encrypted data depends on the secrecy of the 42 key needed to decrypt it. If one key is able to decrypt large 43 quantities of data, its compromise will be disastrous. This memo 44 describes three methods for limiting this vulnerability for OpenPGP 45 messages: reducing the lifetime of confidentiality keys; one-time 46 pads; and the additional use of lower-layer security services. 48 ----------------------------------------------------------------------- 50 Table of Contents 52 1. Introduction 2 53 2. Short-lifetime encryption keys 3 54 2.1 Key generation and distribution 3 55 2.2 Key surrender 4 56 3. One-time keys 4 57 4. One-time pads 6 58 4.1 One-time pad storage 6 59 4.2 One-time pad reference 6 60 4.3 One-time pad encryption 7 61 5. Secure and decentralised e-mail transport 7 62 6. Security considerations 8 63 7. Acknowledgements 8 64 8. Authors 8 65 9. References 8 66 10. Full Copyright Statement 9 68 1. Introduction 70 OpenPGP systems [1] allow two strangers to communicate privately. 71 Each user has a public key that is widely disseminated, and a 72 private key that they keep secret. A message encrypted with a 73 public key can only be decrypted with the related private key. 74 The confidentiality of all messages encrypted with a public key 75 rests on the secrecy of the associated private key. 77 Online systems such as Secure IP [2] can negotiate new keys for 78 every communication using an algorithm like Diffie-Hellman [3]. 79 If a key is compromised, only the specific session it protected 80 will be revealed to an attacker. This desirable property is 81 called perfect forward secrecy. The security of previous or 82 future encrypted sessions is not affected. Keys are securely 83 deleted after use. Without these keys, there is no way captured 84 ciphertext can be decrypted. 86 It is more difficult to make store and forward systems like e-mail 87 forward secret, as they rarely make direct connections between a 88 message sender and its recipient. In a typical e-mail encryption 89 system, users create a long-term key pair and publish the public 90 key in a directory, on their Web page, or via other methods. While 91 the use of long-term keys reduces the administrative burden of key 92 distribution, the practice introduces vulnerabilities. If a public 93 key is used for several years, as is common with OpenPGP systems, 94 compromise of the private key will allow an attacker to decrypt any 95 message captured during that time. 97 This memo describes several methods of reducing the vulnerabilities 98 introduced by use of long-term keys. They are a series of options 99 that MAY be implemented by OpenPGP clients for increased security. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in RFC 2119. 105 ----------------------------------------------------------------------- 107 2. Short-lifetime encryption keys 109 Using a series of encryption keys, each with a short lifetime, 110 reduces the information revealed by the compromise of any one 111 private key because each key protects less data. If expired keys 112 are securely deleted, attackers will never be able to retrieve 113 them to decrypt captured ciphertext. Therefore when a public 114 encryption key expires, an OpenPGP client MUST securely wipe the 115 corresponding private key [4,5]. 117 Deletion should take place once all messages that could have been 118 sent before expiry have been received and decrypted. For example, 119 as a user logs on, their mail client SHOULD retrieve and decrypt 120 all messages from their mail server before deleting any 121 newly-expired private keys. A "panic mode" MAY bypass this step. 123 PGP clients are able to group "subkeys" together under a long-term 124 signature key to signify their common ownership by one principal. 125 To simplify key management, short lifetime keys SHOULD be created 126 as subkeys of their owner's long-term signature key. 128 Clients MAY warn senders of messages encrypted with an expired key 129 that they should not use that public key again. 131 Clients MUST warn all senders of messages encrypted with a revoked 132 key that they should not use that public key again. Any relevant 133 key revocation certificates MUST be included in the warning. 135 Some OpenPGP systems currently store original message ciphertext 136 and decrypt only for display. While this protects messages on 137 disk, it means that keys must be stored until all messages they 138 protect are deleted. We must assume that an attacker has copies 139 of message ciphertext sent over an insecure network such as the 140 Internet. These messages remain vulnerable until the corresponding 141 private key is deleted. 143 Messages therefore MAY be stored temporarily encrypted with a 144 short-lifetime key, but NOT any longer than the key's lifetime; 145 they are unreadable once it has been deleted. Clients MUST allow 146 messages to be stored encrypted under a long-term storage key. A 147 mail client MAY implement its own secure storage facilities, or 148 use those provided by other software. 150 2.1 Key generation and distribution 152 There is a trade-off for the user: the cost of generating and 153 distributing a new encryption key against the security advantage 154 obtained by earlier key expiry. 156 Key generation is typically a time-consuming operation. The client 157 SHOULD minimise the time required by the user to complete this 158 operation. This can be achieved, for example, by background key 159 generation, or by using trade-offs that speed up key generation 160 with minimal reduction in security. With Elgamal [6], for example, 162 ----------------------------------------------------------------------- 163 the expensive key component to generate is the public prime 164 modulus. A group of keys can share a common public modulus with no 165 negative security implications other than that the key then 166 presents a fatter target for pre-computation attacks. Multiple 167 forward secret Elgamal keys MAY therefore use the same prime 168 modulus with minimal security reduction. 170 Key distribution can be eased by submitting new keys to key 171 servers, where they will be available for other users to retrieve. 172 Submission and retrieval of generally-available public keys SHOULD 173 be performed automatically by software. Expired public encryption 174 keys MAY be deleted by users and keyservers to save space. 176 If an OpenPGP client has more than one valid encryption key 177 available for a given message recipient, the key nearest its 178 expiration date MUST be used. This limits the time during which the 179 corresponding private key will be available to an attacker. The 180 time required to deliver a message should be taken into account 181 when checking an expiry date. 183 Signature keys that are long-lived and certified by other users 184 allow a web of trust to build up. Encryption keys SHOULD be 185 certified by a user's long-term signature key to allow their 186 verification by other users. 188 2.2 Key surrender 190 Before an OpenPGP client exports a private key as plaintext, the 191 associated public key MUST be revoked and redistributed. A "reason 192 for revocation" signature subpacket MUST be included in the key 193 revocation specifying "Key material has been compromised" (value 194 0x02). 196 3. One-time keys 198 Taking short-term keys to their logical conclusion, a different key 199 could be used to protect every message. Schneier and Hall [7] 200 suggested a user could make several public keys available in a 201 directory. After a key was retrieved by another user, it would be 202 deleted. This requires message senders to have online access to a 203 directory. Not all e-mail users have this facility. It also allows 204 an attacker to mount a denial of service attack by exhaustively 205 requesting new one-time keys from the directory. 207 An off-line scheme is more compatible with the store and forward 208 nature of e-mail, and resistant to DoS. Every time a user sends a 209 message encrypted with a public key whose signature includes a one- 210 time key support subpacket, they SHOULD include a new one-time 211 public subkey for the recipient to encrypt any reply with. It MUST 212 be sent in the format [primary public signing key | one-time public 213 subkey | signature by primary key]. If PGP/MIME [8] support is 214 available, new key(s) MUST be sent in a separate application/pgp- 215 keys MIME bodypart. 217 ----------------------------------------------------------------------- 218 One-time subkeys MUST NOT be exported by their recipient to a third 219 party, particularly a key server. 221 Users still MUST possess a relatively long-lived encryption key. If 222 Alice were writing to Bob for the first time, she would encrypt her 223 message with his long term key. She would also include a newly 224 created one-time public subkey. Bob would use this new key the next 225 time he wrote to Alice, then wipe it. Alice would decrypt the 226 message with the associated private subkey, then delete it. 228 A "one-time key support" signature subpacket on a public key 229 indicates support for one-time keys. These subpackets are formatted 230 as follows: 232 Subpacket length: 1 233 Subpacket type: 30 235 One-time key support subpackets MUST be included in the hashed area 236 of a signature. 238 A "one-time key" signature subpacket marker MUST be present in the 239 signature of a one-time subkey. These subpackets are formatted as 240 follows: 242 Subpacket length: 1 243 Subpacket type: 158 245 One-time key subpackets MUST be included in the hashed area of a 246 signature. They are marked as critical so that the entire signature 247 will be ignored by non-compliant OpenPGP clients, preventing more 248 than one message being encrypted using a one-time subkey. 250 When encrypting messages to a key with a signature containing a 251 one-time key support subpacket, at least one new public encryption 252 subkey MUST be included in the message. This key MUST be signed by the 253 sender's long-term signature key and include a one-time key 254 signature subpacket. It MUST have a short lifetime of less than 30 255 days, beyond which time the recipient is unlikely to reply to the 256 message. This minimises the key storage requirements of sender and 257 recipient. As a user's collection of private keys grows, she may 258 wish to reduce the lifetime of new one-time subkeys. 260 A client MUST include further new public encryption subkeys if it 261 believes a message will receive multiple replies, each of which 262 SHOULD be encrypted with a different subkey if available. 264 Clients MUST delete a one-time subkey after successfully encrypting 265 data using it. They SHOULD use a one-time subkey, if available, in 266 preference to short-lifetime key. 268 ----------------------------------------------------------------------- 270 4. One-time pads 272 The one-time pad is the only provably secure cipher [9]. It uses a 273 secret key as long as the plaintext; the key is XOR'd with the 274 plaintext to give the ciphertext, and with the ciphertext to give 275 the plaintext. Each secret key MUST only be used once. Compromise 276 of key data allows decryption only of the matching ciphertext. 277 A key can always be generated that will create any given plaintext 278 of the same length from a piece of ciphertext. 280 While the OTP may be considered overkill for most OpenPGP 281 applications, particularly given the far greater insecurities 282 present in common applications and operating systems, it can be 283 useful for ultra-secure communication between two parties who have 284 already securely physically exchanged key material out of band. OTP 285 keys MUST NOT be transferred by a less secure method, for example 286 using any other cipher. A OTP SHOULD only be used in a trusted 287 computing environment: to do otherwise gives a false assurance of 288 security. 290 4.1 One-time pad storage 292 One-time pad data MUST be securely transferred out-of-band. An 293 application SHOULD store pad data in a Literal packet (tag 11). 294 The body of the packet consists of: 296 - One octet 'o' (0x6f) specifying binary one-time pad data. 298 - One octet 0x00 specifying no file name. 300 - A four octet date specifying the creation time of the packet. 302 - The one-time pad. 304 4.2 One-time pad reference 306 A one-time pad reference is used to tell a message recipient which 307 pad data to use to decrypt the following encrypted packet. It is 308 stored in a Symmetric-Key Encrypted Session-Key Packet (Tag 3). 310 The body of this packet consists of: 312 - A one-octet version number. The only currently defined version 313 is 4. 315 - A one-octet number describing the symmetric algorithm used: 14. 317 - 0x0000 to specify that the reference is not encrypted. 319 - A four-octet date when the referenced one-time pad was created. 321 - A four-octet offset specifying the first octet in the referenced 322 pad that should be used as key. 324 ----------------------------------------------------------------------- 326 4.3 One-time pad encryption 328 Data encrypted with a one-time pad is stored in a Symmetrically 329 Encrypted Data Packet (Tag 9) using a cipher value of 14. Its body 330 is simply a valid OpenPGP message (typically consisting of literal 331 or compressed data packets) exclusive-OR'd with the one-time pad 332 data referred to by the preceding one-time pad reference. 334 Once a message recipient has decrypted a one-time pad message, it 335 MUST securely delete the one-time pad data used. 337 Clients SHOULD use a one-time pad, if available, in preference to 338 one-time or short-lifetime keys. 340 5. Secure and decentralised e-mail transport 342 The vast majority of current mail clients deliver messages first to 343 a local mail server, which forwards them to their recipient's mail 344 server, where they remain until collected. This procedure minimises 345 security because it fails to take advantage of mail transport 346 protocols such as SMTP [10] over secure transport or network layer 347 security links such as TLS [11] or IPSEC [2]. This is particularly 348 important given that these protocols allow transient keys to be 349 generated and then discarded after each session, providing perfect 350 forward secrecy. 352 End-to-end security would be better provided if clients delivered 353 messages directly to the recipient's mail server. This allows a 354 secure link to be set up between the two, providing a second layer 355 of forward secrecy. Ideally, as greater numbers of users gain 356 permanent Internet connections through cable modems or Digital 357 Subscriber Lines, they can run mail servers on their own machines. 358 DNS Mail eXchange records [12] can be used to specify a backup mail 359 server such as at an ISP for times when the recipient's machine is 360 unavailable. 362 OpenPGP mail clients SHOULD deliver messages directly to the 363 recipient's mail server, and MUST use any available lower layer 364 security services to protect the links used to deliver messages. 366 Where OpenPGP keys are used in such services, they SHOULD NOT be 367 used to encrypt keying material that can later be decrypted if 368 they are compromised. Ideally, they SHOULD be used only to 369 authenticate a forward-secret key negotiation protocol such as 370 Diffie-Hellman [3]. At the least, new short-lifetime key pairs 371 SHOULD be generated for key encryption use. 373 Direct delivery of mail can reveal the sender and recipient of 374 messages to traffic analysts. Clients MAY use anonymous remailers 375 [13] or IP [14] services to mask this information. 377 ----------------------------------------------------------------------- 379 6. Security Considerations 381 As mentioned in section 4, users of these extensions must consider 382 the complete security environment in which they are operating. 383 Highly-secure communications are of limited use between two 384 insecure systems vulnerable to hackers, virii, and other methods of 385 message and key compromise at source. Bellovin [15] describes a 386 minimum set of precautions that should be taken. 388 7. Acknowledgements 390 Thanks to Nick Bohm, Richard Clayton, Hal Finney and Edwin Woudt 391 for suggestions that have been incorporated into this draft. 393 8. Authors' Addresses 395 Ian Brown 396 Department of Computer Science 397 University College London 398 Gower Street 399 London WC1E 6BT 400 United Kingdom 402 Phone: +44 20 7679 3716 403 Fax: +44 20 7387 1397 404 E-mail: I.Brown@cs.ucl.ac.uk 406 Adam Back 407 Zero-Knowledge Systems Inc. 408 888 de Maisonneuve East 409 6th Floor 410 Montreal 411 Quebec H2L 4S8 412 Canada 414 E-mail: adam@cypherspace.org 416 Ben Laurie 417 A.L. Digital Ltd. 418 Voysey House 419 Barley Mow Passage 420 London W4 4GB 421 United Kingdom 423 Phone: +44 (20) 8735 0686 424 E-mail: ben@algroup.co.uk 426 9. References 428 [1] Callas, J., Donnerhacke, L., Finney, H. and Thayer, R., 429 "OpenPGP Message Format", RFC 2440, November 1998. 431 [2] Atkinson, R., "Security Architecture for the Internet 432 Protocol", RFC 1825, August 1995. 434 ----------------------------------------------------------------------- 436 [3] Diffie, W. and Hellman, M., "New directions in cryptography", 437 IEEE Transactions on Information Theory 22(6), November 1976, 438 644-654. 440 [4] US Department of Defense, "Department of Defense Trusted 441 Computer System Evaluation Criteria", DoD 5200.28-STD, 442 December 1985. 444 [5] Crescenzo, G. de, Ferguson, N., Impagliazzo, R. and Jakobsson, 445 M., "How To Forget a Secret", Proc. Symposium on Theoretical 446 Aspects in Computer Science, Trier, Germany, March 1999. 448 [6] Elgamal, T., "A Public Key Cryptosystem and a Signature Scheme 449 Based on Discrete Logarithms", IEEE Transactions on 450 Information Theory 31(4), July 1985, 469-472. 452 [7] Schneier, B. and Hall, C., "An Improved E-mail Security 453 Protocol", Proc. 13th Annual Computer Security Applications 454 Conference, New York: ACM Press, 1997, pp. 232-238. 456 [8] Elkins, M., Del Torto, D., Levien, R. and Roessler, T., "MIME 457 Security with OpenPGP", IETF work in progress, April 2000. 459 [9] Schneier, B., "Applied Cryptography", New York: Wiley, 1996, 460 p.15. 462 [10] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 463 1982. 465 [11] Dierks, T. and Allen, C., "The TLS Protocol", RFC 2246, 466 November 1997. 468 [12] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 469 13, RFC 1034, November 1987. 471 [13] Chaum, D., "Untraceable Electronic Mail, Return Addresses, and 472 Digital Pseudonyms", Communications of the ACM 24(2) 84-88, 473 February 1981. 475 [14] Reed, M. G., Syverson, P. F. and Goldschlag, D. M., 476 "Anonymous Connections and Onion Routing", IEEE Journal on 477 Selected Areas in Communication Special Issue: Copyright and 478 Privacy Protection, May 1998. 480 [15] Bellovin, S., "Can Someone Read My E-Mail?", 481 http://www.research.att.com/~smb/securemail.html, 1998. 483 10. Full Copyright Statement 485 Copyright (C) The Internet Society (2000). All Rights Reserved. 487 This document and translations of it may be copied and furnished to 488 others, and derivative works that comment on or otherwise explain it 489 or assist in its implementation may be prepared, copied, published 491 ----------------------------------------------------------------------- 492 and distributed, in whole or in part, without restriction of any 493 kind, provided that the above copyright notice and this paragraph 494 are included on all such copies and derivative works. However, this 495 document itself may not be modified in any way, such as by removing 496 the copyright notice or references to the Internet Society or other 497 Internet organizations, except as needed for the purpose of 498 developing Internet standards in which case the procedures for 499 copyrights defined in the Internet Standards process must be 500 followed, or as required to translate it into languages other than 501 English. 503 The limited permissions granted above are perpetual and will not be 504 revoked by the Internet Society or its successors or assigns. 506 This document and the information contained herein is provided on an 507 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 508 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 509 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 510 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 511 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 -----------------------------------------------------------------------