idnits 2.17.1 draft-klensin-rfc2821-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 426. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 8, 2005) is 6864 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 2821 (ref. '1') (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft July 8, 2005 4 Expires: January 9, 2006 6 Security Considerations Issues for RFC 2821bis 7 draft-klensin-rfc2821-security-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 RFC 3552 is a useful analysis and presentation of recommendations for 41 Security Considerations Sections. Part of its content is an 42 extensive analysis of, and proposed replacement for, the Security 43 Considerations section of RFC 2821. In important respects, the 44 proposed replacement text may not be appropriate for this type of 45 document. It also raises some specific issues that may not be 46 consistent with the consensus community of email experts about best 47 practice. Given the way it is worded, and the fact that it was 48 published as a BCP document, it is plausible to consider it as an 49 Update to RFC 2821 and to consider its "example" to be normative for 50 any future revision of RFC 2821 such as the work that has been 51 started in [7]. Those perceptions should be definitively evaluated 52 and corrected if necessary. This document is a first step in doing 53 so and also makes some specific additional suggestions about the 54 handling of Security Considerations material. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Practical Application of RFC 3552 . . . . . . . . . . . . . . 4 60 3. Mail Principles and Security . . . . . . . . . . . . . . . . . 4 61 4. Section by Section Analysis of the Replacement Section . . . . 5 62 4.1 Section 6.1.1.1: Discussion of IDENT . . . . . . . . . . . 5 63 4.2 Section 6.1.1.3: Security value of disabling VRFY . . . . 6 64 4.3 Section 6.1.1.8: Spam . . . . . . . . . . . . . . . . . . 6 65 4.4 Section 6.1.2: Communications Security . . . . . . . . . . 7 66 4.5 6.1.3: Denial of Service . . . . . . . . . . . . . . . . . 7 67 4.6 Additional Material for 2821bis . . . . . . . . . . . . . 7 68 5. Conclusion and Recommendations . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 73 8.2 Informative References . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 75 Intellectual Property and Copyright Statements . . . . . . . . 10 77 1. Introduction 79 RFC 3552 [2] is a useful analysis and presentation of recommendations 80 for Security Considerations Sections. Part of its content is an 81 extensive analysis of, and proposed replacement for, the Security 82 Considerations section of RFC 2821 [1] (SMTP). In important 83 respects, the proposed replacement text may not be appropriate for 84 the type of document that RFC 2821 represents, namely a unified 85 description and collection of clarifications to a widely-deployed and 86 very established protocol. This document suggests that RFC 3552 87 should have made a distinction between the intent of Security 88 Considerations sections for a new protocol at or before early stages 89 of deployment and a mature and widely deployed protocol. For early- 90 stage protocols, the activity of constructing a Security 91 Considerations section and working through the issues involved may 92 result in significant improvements to the protocol itself. By 93 contrast, for a protocol as well-established and widely deployed as 94 SMTP, the security issues are, to paraphrase a discussion with one of 95 RFC 3552's authors, essentially what they are: the construction and 96 review of a Security Considerations section is unlikely to have any 97 significant impact on how the protocol is designed or operates, 98 although a security analysis may be helpful in making operational 99 decisions. 101 The proposed replacement text may also not reflect consensus of the 102 community of email experts about best practice, especially in the 103 area of address-based blacklist filtering for spam. That document 104 can be interpreted as suggesting that it is reasonable to expect that 105 a document specifying email transport should be required to contain 106 an analysis of at least a very large fraction, and perhaps even a 107 comprehensive listing, of the ways in which email could be attacked 108 or misused, or how one might (reasonably or otherwise) defend against 109 those attacks. 111 This author believes that level of analysis would be extremely 112 useful. Considerable analysis is, however, required. Moveover, the 113 security environment for Internet applications often evolves much 114 more rapidly than the applications, especially the more mature ones, 115 do themselves. This combination suggests that, at least for mature 116 and widely-deployed protocols, the analysis is better prepared 117 separately and placed in a document separate from the protocol 118 specification itself. 120 Put differently, there is unquestionably a place for complete 121 security analyses of a protocol and its applications and 122 implementations. Such work is certainly valuable when it can be 123 produced, but expecting such an analysis, or even a near 124 approximation to it, as part of a "security considerations" section 125 -- the adequate completion of which is prerequisite to approval and 126 publication of any document that comes through the IETF process-- is 127 probably unwise when the base document reflects clarifications and 128 document unification for a mature protocol. A statement of known 129 risks in the design and use of the protocol --or even a statement 130 that the protocol is sufficiently insecure that it should be used 131 only in a highly-protected and isolated environment -- is certainly 132 reasonable and appropriate. But a normative presentation and 133 analysis of suggestions of some subset of ways to resist certain 134 misuses of the protocol by end users might reasonably be the subject 135 of other documents, and even standards, but it is inappropriate to 136 require it as part of the "security considerations" section of the 137 base protocol. 139 Given the way RFC3552 is worded, and the fact that it was published 140 as a BCP document, it is plausible to consider it as an update to RFC 141 2821 (i.e., replacing the Security Considerations section of that 142 document) and to consider its "example" to be normative for any 143 future revision of RFC 2821. Those perceptions should be 144 definitively evaluated and corrected if necessary. This document is 145 a first step in doing so and also makes some specific additional 146 suggestions about the status, in practice, of RFC 3552 and the 147 handling of Security Considerations material for mature and deployed 148 standards. 150 2. Practical Application of RFC 3552 152 The author has extracted a convenience sample of a dozen, 153 specifications whose principal focus was not security, approved as 154 Proposed Standards in the two years since RFC 3552 was published. If 155 the documents examined were representative, they would suggest that 156 RFC 3552 has been generally ignored, with few if any of those 157 documents meeting all of its requirements for identification of 158 possible threats and discussion of proposed threat-protection 159 mechanisms that would not work. Perhaps it would be reasonable to 160 conclude from this that it should be ignored in constructing the 161 replacement for RFC 2821 as well. However, since RFC 2821 is singled 162 out as an example, that seems unwise and this document is supplied to 163 initiate a specific discussion in the context of unfolding work up an 164 update to RFC 2821 [7]. (Cf. Section 5.) 166 3. Mail Principles and Security 168 It is a long-standing principle of email on the Internet and 169 elsewhere, and, indeed, of most postal mail systems, that the mail 170 should, if at all possible, go through and that, if it does not go 171 through, the failure should be indicated through established and 172 standardized mechanisms. As RFC 2821 points out, it is entirely 173 rational for mail systems to make operational exceptions to that 174 principle and to, e.g., drop mail without making great efforts to 175 return it, if they know they are under attack. But the principle 176 remains: rejecting, discarding, or blocking mail that cannot be 177 positively identified as hostile or otherwise unwanted is generally 178 considered extremely undesirable. Indeed, doing so can create a 179 security risk, since it is possible that an incorrectly-discarded 180 message might contain information that was critical to the intended 181 recipient. 183 Consequently, while feelings often run very high about where the 184 lines should be drawn, any system for mail filtering and rejection 185 for other than undeliverability or known inaccessibility to the 186 intended recipient must be considered a tradeoff between improved 187 safety or convenience and the risk of incorrect rejections. 189 4. Section by Section Analysis of the Replacement Section 191 Section 5 of RFC 3552 requires identifying, as a strong requirement 192 (i.e., with "MUST" language as defined in [4]) the range of attacks 193 that are possible on a protocol, those that are not relevant ("out of 194 scope"), and what attacks it protects against. Perhaps only because 195 of the differences between new protocols and those that are mature 196 and widely deployed, these requirements may not, as written be 197 appropriate for SMTP. With a protocol as old and established as 198 SMTP, the security issues are generally well understood, much more so 199 than with a protocol that has not yet been extensively tested by 200 experience. One way to look at this is that, for a newer protocol, 201 we have Security Considerations and their influence on the design or 202 applicability of the protocol itself. For SMTP, a security analysis 203 is useful and important. Such an analysis might include suggestions 204 about, e.g., the configuration of an SMTP implementation for use 205 under various circumstances but is necessarily somewhat different 206 from one written to describe risks and issues in a new protocol. 208 Familiarity with RFC 3552 section 5, and the SMTP-specific material 209 in section 6.1, is assumed in the material that follows. The section 210 numbers cited are in RFC 3552. 212 4.1 Section 6.1.1.1: Discussion of IDENT 214 IDENT [3] is a Proposed Standard. If one agrees with the analysis in 215 3552, the appropriate action would be to deprecate IDENT, or generate 216 an appropriate applicability statement about it, not to simply insert 217 comments into the SMTP specification. The text and examples of 3552 218 can be read to suggest is a requirement to discuss every unfortunate 219 or ineffective approach to SMTP security. If that were to be the 220 goal, then discussions on the IETF-based SMTP and anti-spam mailing 221 lists during the year preceeding July 2005 present a legion of 222 opportunities, most of them more problematic than IDENT. The IDENT 223 material probably does not belong in RFC 2821, although a pointer to 224 a discussion if IDENT, and a number of ideas with similar intent, 225 would be entirely appropriate. 227 4.2 Section 6.1.1.3: Security value of disabling VRFY 229 RFC 3552 suggests adding a note indicating that disabling VRFY may 230 not have much security value since the same information may be 231 available from RCPT TO. If this is going to be said, it should be 232 associated with a more complete discussion of when VRFY does actually 233 produce more information that RCPT TO, e.g., when address processing 234 is deferred for the latter, as the mail specifications have permitted 235 for years. The text in the initial draft of 2821bis has been 236 modified to reflect that point. The statement and recommendation in 237 RFC 3552 appears to be too simplistic in this area. So, if a 238 subsection of a Security Considerations were to discuss issues with 239 VRFY, it would presumably need to pick up (or point to), considerable 240 material that already appears elsewhere in RFC 2821 and avoid some of 241 the pitfalls identified there. 243 4.3 Section 6.1.1.8: Spam 245 RFC 3552 recommends including an extended discussion of spam-fighting 246 issues in the SMTP specification, citing and expanding on [6]. The 247 email-expert portion of the IETF community has repeatedly reached 248 rough consensus that the base email transport and message headers and 249 body specifications should be kept free of operational 250 considerations, particularly those concerned with spam-fighting and 251 spam-resistance, other than to note areas of the specifications in 252 which exceptions can be made when operationally necessary. The 253 various efforts in the IETF and IRTF to develop anti-spam 254 specifications and techniques have generally been instructed to stay 255 away from modifications to the base email specifications (although 256 they may, and have, created compatible extensions to them). Yet RFC 257 3552 proposes to override that consensus and those agreements to 258 include a spam-fighting discussion in RFC 2821 and its successors. 260 Worse, the text proposed in 3552 appears to recommend "blacklisting" 261 techniques of various sorts, going so far as to identify particular 262 sources of blacklists. While they were more popular a few years ago 263 than they are today, it would be a significant understatement to 264 suggest that these techniques are controversial in the email 265 community and that there is no IETF consensus to recommend them as 266 appropriate. 268 4.4 Section 6.1.2: Communications Security 270 In the opinion of this author, this material is quite good. It 271 belongs somewhere, but probably not in the SMTP specification. For 272 that specification, it goes fairly far into message header issues 273 (normally the provence of other specifications), it explores 274 difficulties in other protocols, such as the use of IPSEC, and so 275 forth. In addition, it suffers from some of the same difficulties 276 discussed above in Section 4.2: if one is going to go into these 277 areas in the context of SMTP, some of the discussion is insufficient 278 and incomplete. 280 4.5 6.1.3: Denial of Service 282 Again, while there is nothing wrong with this new material, it is not 283 clear that it is adequate in the SMTP context. Singling out one 284 specific implementation for one of its idiosyncracies seems 285 particularly inappropriate. If one is going to examine DoS attacks 286 in the SMTP context, perhaps the most important issue --certainly an 287 important issue-- involves tuning of the various SMTP timeouts. That 288 is a hot topic on many discussion lists, especially those concerned 289 with spam fighting, and has been for years. Additionally, there are 290 specific, standards-track, SMTP extensions (including [5], a Full 291 Standard) that can be used to manage some of the issues this section 292 raises (in the case of RFC 1870, the excessive disk usage problem) 293 but are not mentioned in the discussion that RFC 3552 supplies. 294 Where is it appropriate for the security considerations material of 295 RFC 2821 us stop, given the level of detail provided in other 296 subsections? 298 4.6 Additional Material for 2821bis 300 Interestingly, there are a wide range of topics that might 301 appropropriately be covered in a security analysis of SMTP that the 302 RFC 3552 analysis odes not cover. They include a more comprehensive 303 treatment of approrpriate and inappropriate actions in dealing with 304 mail that is presumed to be hostile, the among and type of logging 305 and reporting that should be maintained for mesages that are dropped, 306 various authentication frameworks and the problems they do and do not 307 solve, and so on. The likely extent of that material again suggests 308 that it would be better placed in a separate "mail security analysis" 309 document than forced into the SMTP specification. 311 5. Conclusion and Recommendations 313 The tone and several of the requirements imposed by RFC 3552 are 314 dubious, especially when applied to documents describing mature and 315 widely-deployed protocols. For such protocols, the most likely 316 impact of strict application of 3552 as written would be to further 317 discourage applicability statements, standards that consolidate prior 318 work (in the case of SMTP, much of it already at a full Standard 319 level), and documents created to raise the maturity level of the 320 specifications, by imposing a burdensome analysis and documentation 321 requirement. We have too few of such documents as it is; they should 322 be made more burdensome to create only after careful consideration by 323 the community. It is also problematic to require, as RFC 3552 can be 324 interpreted as requiring, that the security considerations section of 325 every protocol specification either contain a discussion of every 326 other protocol that might be used with it or point to a discussion of 327 that protocol that was adequate under 3552's rules. Security 328 analysis of collections of protocols is probably better left to 329 stand-alone documents that can be referred to from individual members 330 of the collection. 332 Perhaps fortunately, the IESG has apparently ignored the requirements 333 of RFC 3552 in a number of specifications it has approved for the 334 standard track subsequent to 3552's publication. Of course, that 335 creates a different problem, one of having procedural BCPs that are 336 approved by the IESG and then ignored (either globally or 337 selectively). It is hard to argue that such documents are BCPs at 338 all, and their approval is probably indicative of a systemic problem 339 in the IETF. 341 At least in this author's opinion, the discussion in RFC 3552 is 342 quite useful and the suggestions it makes should be given serious 343 consideration. The difficulties arise when its text --all of its 344 text-- are considered normative for other specifications, especially 345 specifications that describe mature and widely-deployed protocols. 346 Its BCP status, and the use of strong normative requirement language 347 from RFC 2119, certainly implies that it should be considered 348 normative in that way and that situation probably requires some 349 clarification. 351 6. Security Considerations 353 This document is about an effort to refine the specification for 354 security considerations sections, especially in the context of 355 updated descriptions for mature and widely-deployed protocols. It 356 does not, itself, have any impact on protocol security. 358 7. Acknowledgements 360 Thanks to Ted Hardie and a brief discussion during an Applications 361 Area meeting that led to the suggestion that a document like this one 362 was the right way to pursue this problem. Thanks also to the several 363 people who encouraged me to not just write off 2821bis in the light 364 of the discovery of the provisions of 3552. And thanks especially to 365 Eric Rescorla for his extensive and helpful discussion of issues in 366 RFC 3552 and an earlier version of this document. 368 8. References 370 8.1 Normative References 372 [1] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 373 April 2001. 375 [2] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 376 Security Considerations", BCP 72, RFC 3552, July 2003. 378 8.2 Informative References 380 [3] Mindel, J. and R. Slaski, "FTP-FTAM Gateway Specification", 381 RFC 1415, January 1993. 383 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 384 Levels", BCP 14, RFC 2119, March 1997. 386 [5] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension 387 for Message Size Declaration", STD 10, RFC 1870, November 1995. 389 [6] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, 390 RFC 2505, February 1999. 392 [7] Klensin, J., "Simple Mail Transfer Protocol", July 2005. 394 Author's Address 396 John C Klensin 397 1770 Massachusetts Ave, #322 398 Cambridge, MA 02140 399 USA 401 Phone: +1 617 491 5735 402 Email: john-ietf@jck.com 404 Intellectual Property Statement 406 The IETF takes no position regarding the validity or scope of any 407 Intellectual Property Rights or other rights that might be claimed to 408 pertain to the implementation or use of the technology described in 409 this document or the extent to which any license under such rights 410 might or might not be available; nor does it represent that it has 411 made any independent effort to identify any such rights. Information 412 on the procedures with respect to rights in RFC documents can be 413 found in BCP 78 and BCP 79. 415 Copies of IPR disclosures made to the IETF Secretariat and any 416 assurances of licenses to be made available, or the result of an 417 attempt made to obtain a general license or permission for the use of 418 such proprietary rights by implementers or users of this 419 specification can be obtained from the IETF on-line IPR repository at 420 http://www.ietf.org/ipr. 422 The IETF invites any interested party to bring to its attention any 423 copyrights, patents or patent applications, or other proprietary 424 rights that may cover technology that may be required to implement 425 this standard. Please address the information to the IETF at 426 ietf-ipr@ietf.org. 428 Disclaimer of Validity 430 This document and the information contained herein are provided on an 431 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 432 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 433 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 434 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 435 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 436 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 438 Copyright Statement 440 Copyright (C) The Internet Society (2005). This document is subject 441 to the rights, licenses and restrictions contained in BCP 78, and 442 except as set forth therein, the authors retain all their rights. 444 Acknowledgment 446 Funding for the RFC Editor function is currently provided by the 447 Internet Society.