idnits 2.17.1 draft-brown-pgp-pfs-01.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 are 16 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 (August 2000) is 8626 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' ** Obsolete normative reference: RFC 821 (ref. '8') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2246 (ref. '9') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 12 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-01.txt University College London 3 Updates: RFC 2440 A. Back 4 Category: INTERNET-DRAFT Zero-Knowledge Systems 5 Expires: 26 February 2001 B. Laurie 6 A.L. Digital Ltd 7 August 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 keys; 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. Secure and decentralised e-mail transport 6 58 5. Security considerations 6 59 6. Acknowledgements 6 60 7. Authors 7 61 8. References 7 62 9. Full Copyright Statement 8 64 1. Introduction 66 OpenPGP systems [1] allow two strangers to communicate privately. 67 Each user has a public key that is widely disseminated, and a 68 private key that they keep secret. A message encrypted with a 69 public key can only be decrypted with the related private key. 70 The confidentiality of all messages encrypted with a public key 71 rests on the secrecy of the associated private key. 73 Online systems such as IPSEC [2] can negotiate new keys for 74 every communication using an algorithm like Diffie-Hellman [3]. 75 If a key is compromised, only the specific session it protected 76 will be revealed to an attacker. This desirable property is 77 called perfect forward secrecy. The security of previous or 78 future encrypted sessions is not affected. Keys are securely 79 deleted after use. Without these keys, there is no way captured 80 ciphertext can be decrypted. 82 It is more difficult to make store and forward systems like e-mail 83 forward secret, as they rarely make direct connections between a 84 message sender and its recipient. In a typical e-mail encryption 85 system, users create a long-term key pair and publish the public 86 key in a directory, on their Web page, or via other methods. While 87 the use of long-term keys reduces the administrative burden of key 88 distribution, the practice introduces vulnerabilities. If a public 89 key is used for several years, as is common with OpenPGP systems, 90 compromise of the private key will allow an attacker to decrypt any 91 message captured during that time. 93 This memo describes several methods of reducing the vulnerabilities 94 introduced by use of long-term keys. They are a series of options 95 that MAY be implemented by OpenPGP clients for increased security. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in RFC 2119. 101 ----------------------------------------------------------------------- 103 2. Short-lifetime encryption keys 105 Using a series of encryption keys, each with a short lifetime, 106 reduces the information revealed by the compromise of any one 107 private key because each key protects less data. If expired keys 108 are securely deleted, attackers will never be able to retrieve 109 them to decrypt captured ciphertext. Therefore when a public 110 encryption key expires, an OpenPGP client MUST securely wipe the 111 corresponding private key [4]. 113 Deletion should take place once all messages that could have been 114 sent before expiry have been received and decrypted. For example, 115 as a user logs on, their mail client SHOULD retrieve and decrypt 116 all messages from their mail server before deleting any 117 newly-expired private keys. A "panic mode" MAY bypass this step. 119 PGP clients are able to group "subkeys" together under a long-term 120 signature key to signify their common ownership by one principal. 121 To simplify key management, short lifetime keys SHOULD be created 122 as subkeys of their owner's long-term signature key. 124 Clients receiving messages encrypted with an expired key MAY warn 125 the sender that they should not use that public key again. 127 Clients receiving messages encrypted with a revoked key MUST warn 128 the sender that they should not use that public key again. Any 129 relevant key revocation certificates MUST be included in the 130 warning. 132 Some OpenPGP systems currently store original message ciphertext 133 and decrypt only for display. While this protects messages on 134 disk, it means that keys must be stored until all messages they 135 protect are deleted. We must assume that an attacker has copies 136 of message ciphertext sent over an insecure network such as the 137 Internet. These messages remain vulnerable until the corresponding 138 private key is deleted. 140 Messages therefore MAY be stored temporarily encrypted with a 141 short-lifetime key, but are unreadable once it has been deleted. 142 Clients MUST allow messages to be stored encrypted under a long- 143 term storage key. A mail client MAY implement its own secure 144 storage facilities, or use those provided by other software. 145 Messages SHOULD NOT be encrypted-to-self using a long-term public 146 key. 148 2.1 Key generation and distribution 150 There is a trade-off for the user: the cost of generating and 151 distributing a new encryption key against the security advantage 152 obtained by earlier key expiry. 154 Key generation is typically a time-consuming operation. The client 155 SHOULD minimise the time required by the user to complete this 156 operation. This can be achieved, for example, by background key 158 ----------------------------------------------------------------------- 159 generation, or by using trade-offs that speed up key generation 160 with minimal reduction in security. With Elgamal [5], for example, 161 the expensive key component to generate is the public prime 162 modulus. A group of keys can share a common public modulus with no 163 negative security implications other than that the key then 164 presents a fatter target for pre-computation attacks. Multiple 165 forward secret Elgamal keys MAY therefore use the same prime 166 modulus with minimal security reduction. 168 Key distribution can be eased by submitting new keys to key 169 servers, where they will be available for other users to retrieve. 170 Submission and retrieval of generally-available public keys SHOULD 171 be performed automatically by software. Expired public encryption 172 keys MAY be deleted by users and keyservers to save space. 174 If an OpenPGP client has more than one valid encryption key 175 available for a given message recipient, the key nearest its 176 expiration date MUST be used. This limits the time during which the 177 corresponding private key will be vulnerable to attack. The time 178 required to deliver a message should be taken into account by 179 sender and recipient when checking an expiry date. 181 Signature keys that are long-lived and certified by other users 182 allow a web of trust to build up. Encryption keys SHOULD be 183 certified by a user's long-term signature key to allow their 184 verification by other users. 186 2.2 Key surrender 188 Before an OpenPGP client exports a private key as plaintext, the 189 associated public key MUST be revoked and redistributed. A "reason 190 for revocation" signature subpacket MUST be included in the key 191 revocation specifying "Key material has been compromised" (value 192 0x02). 194 The least compromising key required MUST be the one surrendered. 195 The session key used to encrypt an individual message will often be 196 sufficient. Otherwise, a subkey should be surrendered before a long- 197 term top-level key. Signature keys should not be surrendered unless 198 absolutely necessary. 200 3. One-time keys 202 Taking short-term keys to their logical conclusion, a different key 203 could be used to protect every message. Schneier and Hall [6] 204 suggested a user could make several public keys available in a 205 directory. After a key was retrieved by another user, it would be 206 deleted. This requires message senders to have online access to a 207 directory. Not all e-mail users have this facility. It also allows 208 an attacker to mount a denial of service attack by exhaustively 209 requesting new one-time keys from the directory. 211 An off-line scheme is more compatible with the store and forward 212 nature of e-mail, and resistant to DoS. Every time a user sends a 214 ----------------------------------------------------------------------- 215 message encrypted with a public key whose signature includes a one- 216 time key support subpacket, they SHOULD include a new one-time 217 public subkey for the recipient to encrypt any reply with. It MUST 218 be sent in the format [primary public signing key | one-time public 219 subkey | signature by primary key]. If PGP/MIME [7] support is 220 available, new key(s) MUST be sent in a separate application/pgp- 221 keys MIME bodypart. 223 One-time subkeys MUST NOT be exported by their recipient to a third 224 party, particularly a key server. 226 Users still MUST possess a relatively long-lived encryption key. If 227 Alice were writing to Bob for the first time, she would encrypt her 228 message with his long term key. She would also include a newly 229 created one-time public subkey. Bob would use this new key the next 230 time he wrote to Alice, then delete it. Alice would decrypt the 231 message with the associated private subkey, then securely wipe it. 233 A "one-time key support" signature subpacket on a public key 234 indicates support for one-time keys. These subpackets MUST be 235 included in the hashed area of a signature. They are formatted 236 as follows: 238 Subpacket length: 1 239 Subpacket type: 30 241 A "one-time key" signature subpacket marker MUST be present in the 242 signature of a one-time subkey. These subpackets are formatted as 243 follows: 245 Subpacket length: 1 246 Subpacket type: 158 248 One-time key subpackets MUST be included in the hashed area of a 249 signature. They are marked as critical so that the entire signature 250 will be ignored by non-compliant OpenPGP clients, preventing more 251 than one message being encrypted using a one-time subkey. 253 When encrypting messages to a key with a signature containing a 254 one-time key support subpacket, at least one new public encryption 255 subkey MUST be included in the message. This key MUST be signed by 256 the sender's long-term signature key and include a one-time key 257 signature subpacket. The lifetime of a one-time subkey SHOULD be 258 set to as short a period as possible given the expected response 259 time of the recipient. This minimises the key storage requirements 260 of sender and recipient. As a user's collection of private keys 261 grows, she may wish to reduce the lifetime of new one-time subkeys. 263 A client MUST include further new public encryption subkeys if it 264 believes a message will receive multiple replies. Each reply SHOULD 265 be encrypted with a different subkey if available. 267 Clients MUST delete a one-time subkey after successfully encrypting 268 data using it. They SHOULD use a one-time subkey, if available, in 270 ----------------------------------------------------------------------- 271 preference to a short-lifetime key. 273 4. Secure and decentralised e-mail transport 275 The vast majority of current mail clients deliver messages first to 276 a local mail server, which forwards them to their recipient's mail 277 server, where they remain until collected. This procedure minimises 278 security because it fails to take advantage of mail transport 279 protocols such as SMTP [8] over secure transport or network layer 280 security links such as TLS [9] or IPSEC [2]. This is particularly 281 important given that these protocols allow transient keys to be 282 generated and then discarded after each session, providing perfect 283 forward secrecy. 285 End-to-end security would be better provided if clients delivered 286 messages directly to the recipient's mail server. This allows a 287 secure link to be set up between the two, providing a second layer 288 of forward secrecy. Ideally, as greater numbers of users gain 289 permanent Internet connections through cable modems or Digital 290 Subscriber Lines, they can run mail servers on their own machines. 291 DNS Mail eXchange records [10] can be used to specify a backup mail 292 server such as at an ISP for times when the recipient's machine is 293 unavailable. 295 OpenPGP mail clients therefore SHOULD deliver messages directly to 296 the recipient's mail server, and SHOULD use any available lower 297 layer security services to protect the links used to deliver 298 messages. 300 Where OpenPGP keys are used in such services, they SHOULD NOT be 301 used to encrypt keying material that can later be decrypted if 302 they are compromised. Ideally, they SHOULD be used only to 303 authenticate a forward-secret key negotiation protocol such as 304 Diffie-Hellman [3]. At the least, new short-lifetime key pairs 305 SHOULD be generated for key encryption use. 307 Direct delivery of mail can reveal the sender and recipient of 308 messages to traffic analysts. Clients MAY use anonymous remailers 309 [11] or IP services [12] to mask this information. 311 5. Security Considerations 313 Users of these extensions must consider the complete security 314 environment in which they are operating. Highly-secure 315 communications are of limited use between two insecure systems 316 vulnerable to crackers, virii, and other methods of message and 317 key compromise at source. Bellovin [13] describes a minimum set of 318 precautions that should be taken. 320 6. Acknowledgements 322 Thanks to Nick Bohm, Richard Clayton, Hal Finney and Edwin Woudt 323 for suggestions that have been incorporated into this draft. 325 ----------------------------------------------------------------------- 327 7. Authors' Addresses 329 Ian Brown 330 Department of Computer Science 331 University College London 332 Gower Street 333 London WC1E 6BT 334 United Kingdom 336 Phone: +44 20 7679 3716 337 Fax: +44 20 7387 1397 338 E-mail: I.Brown@cs.ucl.ac.uk 340 Adam Back 341 Zero-Knowledge Systems Inc. 342 888 de Maisonneuve East 343 6th Floor 344 Montreal 345 Quebec H2L 4S8 346 Canada 348 E-mail: adam@cypherspace.org 350 Ben Laurie 351 A.L. Digital Ltd. 352 Voysey House 353 Barley Mow Passage 354 London W4 4GB 355 United Kingdom 357 Phone: +44 (20) 8735 0686 358 E-mail: ben@algroup.co.uk 360 8. References 362 [1] Callas, J., Donnerhacke, L., Finney, H. and Thayer, R., 363 "OpenPGP Message Format", RFC 2440, November 1998. 365 [2] Atkinson, R., "Security Architecture for the Internet 366 Protocol", RFC 1825, August 1995. 368 [3] Diffie, W. and Hellman, M., "New directions in cryptography", 369 IEEE Transactions on Information Theory 22(6), November 1976, 370 644-654. 372 [4] US Department of Defense, "Department of Defense Trusted 373 Computer System Evaluation Criteria", DoD 5200.28-STD, 374 December 1985. 376 [5] Elgamal, T., "A Public Key Cryptosystem and a Signature Scheme 377 Based on Discrete Logarithms", IEEE Transactions on 378 Information Theory 31(4), July 1985, 469-472. 380 [6] Schneier, B. and Hall, C., "An Improved E-mail Security 382 ----------------------------------------------------------------------- 383 Protocol", Proc. 13th Annual Computer Security Applications 384 Conference, New York: ACM Press, 1997, pp. 232-238. 386 [7] Elkins, M., Del Torto, D., Levien, R. and Roessler, T., "MIME 387 Security with OpenPGP", IETF work in progress, August 2000. 389 [8] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 390 1982. 392 [9] Dierks, T. and Allen, C., "The TLS Protocol", RFC 2246, 393 November 1997. 395 [10] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 396 13, RFC 1034, November 1987. 398 [11] Chaum, D., "Untraceable Electronic Mail, Return Addresses, and 399 Digital Pseudonyms", Communications of the ACM 24(2) 84-88, 400 February 1981. 402 [12] Goldberg, I. and Shostack, A., "Freedom Network 1.0 403 Architecture and Protocols", http://www.freedom.net/info/ 404 freedompapers/Freedom-Architecture-Protocols.pdf 406 [13] Bellovin, S., "Can Someone Read My E-Mail?", 407 http://www.research.att.com/~smb/securemail.html, 1998. 409 9. Full Copyright Statement 411 Copyright (C) The Internet Society (2000). All Rights Reserved. 413 This document and translations of it may be copied and furnished to 414 others, and derivative works that comment on or otherwise explain 415 it or assist in its implementation may be prepared, copied, 416 published and distributed, in whole or in part, without restriction 417 of any kind, provided that the above copyright notice and this 418 paragraph are included on all such copies and derivative works. 419 However, this document itself may not be modified in any way, such 420 as by removing the copyright notice or references to the Internet 421 Society or other Internet organizations, except as needed for the 422 purpose of developing Internet standards in which case the 423 procedures for copyrights defined in the Internet Standards process 424 must be followed, or as required to translate it into languages 425 other than English. 427 The limited permissions granted above are perpetual and will not be 428 revoked by the Internet Society or its successors or assigns. 430 This document and the information contained herein is provided on 431 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 433 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 434 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 -----------------------------------------------------------------------