Internet DRAFT - draft-klensin-rfc2821-security
draft-klensin-rfc2821-security
Network Working Group J. Klensin
Internet-Draft July 8, 2005
Expires: January 9, 2006
Security Considerations Issues for RFC 2821bis
draft-klensin-rfc2821-security-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
RFC 3552 is a useful analysis and presentation of recommendations for
Security Considerations Sections. Part of its content is an
extensive analysis of, and proposed replacement for, the Security
Considerations section of RFC 2821. In important respects, the
proposed replacement text may not be appropriate for this type of
document. It also raises some specific issues that may not be
consistent with the consensus community of email experts about best
practice. Given the way it is worded, and the fact that it was
published as a BCP document, it is plausible to consider it as an
Klensin Expires January 9, 2006 [Page 1]
Internet-Draft RFC3552 SMTP Issues July 2005
Update to RFC 2821 and to consider its "example" to be normative for
any future revision of RFC 2821 such as the work that has been
started in [7]. Those perceptions should be definitively evaluated
and corrected if necessary. This document is a first step in doing
so and also makes some specific additional suggestions about the
handling of Security Considerations material.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Practical Application of RFC 3552 . . . . . . . . . . . . . . 4
3. Mail Principles and Security . . . . . . . . . . . . . . . . . 4
4. Section by Section Analysis of the Replacement Section . . . . 5
4.1 Section 6.1.1.1: Discussion of IDENT . . . . . . . . . . . 5
4.2 Section 6.1.1.3: Security value of disabling VRFY . . . . 6
4.3 Section 6.1.1.8: Spam . . . . . . . . . . . . . . . . . . 6
4.4 Section 6.1.2: Communications Security . . . . . . . . . . 7
4.5 6.1.3: Denial of Service . . . . . . . . . . . . . . . . . 7
4.6 Additional Material for 2821bis . . . . . . . . . . . . . 7
5. Conclusion and Recommendations . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Klensin Expires January 9, 2006 [Page 2]
Internet-Draft RFC3552 SMTP Issues July 2005
1. Introduction
RFC 3552 [2] is a useful analysis and presentation of recommendations
for Security Considerations Sections. Part of its content is an
extensive analysis of, and proposed replacement for, the Security
Considerations section of RFC 2821 [1] (SMTP). In important
respects, the proposed replacement text may not be appropriate for
the type of document that RFC 2821 represents, namely a unified
description and collection of clarifications to a widely-deployed and
very established protocol. This document suggests that RFC 3552
should have made a distinction between the intent of Security
Considerations sections for a new protocol at or before early stages
of deployment and a mature and widely deployed protocol. For early-
stage protocols, the activity of constructing a Security
Considerations section and working through the issues involved may
result in significant improvements to the protocol itself. By
contrast, for a protocol as well-established and widely deployed as
SMTP, the security issues are, to paraphrase a discussion with one of
RFC 3552's authors, essentially what they are: the construction and
review of a Security Considerations section is unlikely to have any
significant impact on how the protocol is designed or operates,
although a security analysis may be helpful in making operational
decisions.
The proposed replacement text may also not reflect consensus of the
community of email experts about best practice, especially in the
area of address-based blacklist filtering for spam. That document
can be interpreted as suggesting that it is reasonable to expect that
a document specifying email transport should be required to contain
an analysis of at least a very large fraction, and perhaps even a
comprehensive listing, of the ways in which email could be attacked
or misused, or how one might (reasonably or otherwise) defend against
those attacks.
This author believes that level of analysis would be extremely
useful. Considerable analysis is, however, required. Moveover, the
security environment for Internet applications often evolves much
more rapidly than the applications, especially the more mature ones,
do themselves. This combination suggests that, at least for mature
and widely-deployed protocols, the analysis is better prepared
separately and placed in a document separate from the protocol
specification itself.
Put differently, there is unquestionably a place for complete
security analyses of a protocol and its applications and
implementations. Such work is certainly valuable when it can be
produced, but expecting such an analysis, or even a near
approximation to it, as part of a "security considerations" section
Klensin Expires January 9, 2006 [Page 3]
Internet-Draft RFC3552 SMTP Issues July 2005
-- the adequate completion of which is prerequisite to approval and
publication of any document that comes through the IETF process-- is
probably unwise when the base document reflects clarifications and
document unification for a mature protocol. A statement of known
risks in the design and use of the protocol --or even a statement
that the protocol is sufficiently insecure that it should be used
only in a highly-protected and isolated environment -- is certainly
reasonable and appropriate. But a normative presentation and
analysis of suggestions of some subset of ways to resist certain
misuses of the protocol by end users might reasonably be the subject
of other documents, and even standards, but it is inappropriate to
require it as part of the "security considerations" section of the
base protocol.
Given the way RFC3552 is worded, and the fact that it was published
as a BCP document, it is plausible to consider it as an update to RFC
2821 (i.e., replacing the Security Considerations section of that
document) and to consider its "example" to be normative for any
future revision of RFC 2821. Those perceptions should be
definitively evaluated and corrected if necessary. This document is
a first step in doing so and also makes some specific additional
suggestions about the status, in practice, of RFC 3552 and the
handling of Security Considerations material for mature and deployed
standards.
2. Practical Application of RFC 3552
The author has extracted a convenience sample of a dozen,
specifications whose principal focus was not security, approved as
Proposed Standards in the two years since RFC 3552 was published. If
the documents examined were representative, they would suggest that
RFC 3552 has been generally ignored, with few if any of those
documents meeting all of its requirements for identification of
possible threats and discussion of proposed threat-protection
mechanisms that would not work. Perhaps it would be reasonable to
conclude from this that it should be ignored in constructing the
replacement for RFC 2821 as well. However, since RFC 2821 is singled
out as an example, that seems unwise and this document is supplied to
initiate a specific discussion in the context of unfolding work up an
update to RFC 2821 [7]. (Cf. Section 5.)
3. Mail Principles and Security
It is a long-standing principle of email on the Internet and
elsewhere, and, indeed, of most postal mail systems, that the mail
should, if at all possible, go through and that, if it does not go
through, the failure should be indicated through established and
standardized mechanisms. As RFC 2821 points out, it is entirely
Klensin Expires January 9, 2006 [Page 4]
Internet-Draft RFC3552 SMTP Issues July 2005
rational for mail systems to make operational exceptions to that
principle and to, e.g., drop mail without making great efforts to
return it, if they know they are under attack. But the principle
remains: rejecting, discarding, or blocking mail that cannot be
positively identified as hostile or otherwise unwanted is generally
considered extremely undesirable. Indeed, doing so can create a
security risk, since it is possible that an incorrectly-discarded
message might contain information that was critical to the intended
recipient.
Consequently, while feelings often run very high about where the
lines should be drawn, any system for mail filtering and rejection
for other than undeliverability or known inaccessibility to the
intended recipient must be considered a tradeoff between improved
safety or convenience and the risk of incorrect rejections.
4. Section by Section Analysis of the Replacement Section
Section 5 of RFC 3552 requires identifying, as a strong requirement
(i.e., with "MUST" language as defined in [4]) the range of attacks
that are possible on a protocol, those that are not relevant ("out of
scope"), and what attacks it protects against. Perhaps only because
of the differences between new protocols and those that are mature
and widely deployed, these requirements may not, as written be
appropriate for SMTP. With a protocol as old and established as
SMTP, the security issues are generally well understood, much more so
than with a protocol that has not yet been extensively tested by
experience. One way to look at this is that, for a newer protocol,
we have Security Considerations and their influence on the design or
applicability of the protocol itself. For SMTP, a security analysis
is useful and important. Such an analysis might include suggestions
about, e.g., the configuration of an SMTP implementation for use
under various circumstances but is necessarily somewhat different
from one written to describe risks and issues in a new protocol.
Familiarity with RFC 3552 section 5, and the SMTP-specific material
in section 6.1, is assumed in the material that follows. The section
numbers cited are in RFC 3552.
4.1 Section 6.1.1.1: Discussion of IDENT
IDENT [3] is a Proposed Standard. If one agrees with the analysis in
3552, the appropriate action would be to deprecate IDENT, or generate
an appropriate applicability statement about it, not to simply insert
comments into the SMTP specification. The text and examples of 3552
can be read to suggest is a requirement to discuss every unfortunate
or ineffective approach to SMTP security. If that were to be the
goal, then discussions on the IETF-based SMTP and anti-spam mailing
Klensin Expires January 9, 2006 [Page 5]
Internet-Draft RFC3552 SMTP Issues July 2005
lists during the year preceeding July 2005 present a legion of
opportunities, most of them more problematic than IDENT. The IDENT
material probably does not belong in RFC 2821, although a pointer to
a discussion if IDENT, and a number of ideas with similar intent,
would be entirely appropriate.
4.2 Section 6.1.1.3: Security value of disabling VRFY
RFC 3552 suggests adding a note indicating that disabling VRFY may
not have much security value since the same information may be
available from RCPT TO. If this is going to be said, it should be
associated with a more complete discussion of when VRFY does actually
produce more information that RCPT TO, e.g., when address processing
is deferred for the latter, as the mail specifications have permitted
for years. The text in the initial draft of 2821bis has been
modified to reflect that point. The statement and recommendation in
RFC 3552 appears to be too simplistic in this area. So, if a
subsection of a Security Considerations were to discuss issues with
VRFY, it would presumably need to pick up (or point to), considerable
material that already appears elsewhere in RFC 2821 and avoid some of
the pitfalls identified there.
4.3 Section 6.1.1.8: Spam
RFC 3552 recommends including an extended discussion of spam-fighting
issues in the SMTP specification, citing and expanding on [6]. The
email-expert portion of the IETF community has repeatedly reached
rough consensus that the base email transport and message headers and
body specifications should be kept free of operational
considerations, particularly those concerned with spam-fighting and
spam-resistance, other than to note areas of the specifications in
which exceptions can be made when operationally necessary. The
various efforts in the IETF and IRTF to develop anti-spam
specifications and techniques have generally been instructed to stay
away from modifications to the base email specifications (although
they may, and have, created compatible extensions to them). Yet RFC
3552 proposes to override that consensus and those agreements to
include a spam-fighting discussion in RFC 2821 and its successors.
Worse, the text proposed in 3552 appears to recommend "blacklisting"
techniques of various sorts, going so far as to identify particular
sources of blacklists. While they were more popular a few years ago
than they are today, it would be a significant understatement to
suggest that these techniques are controversial in the email
community and that there is no IETF consensus to recommend them as
appropriate.
Klensin Expires January 9, 2006 [Page 6]
Internet-Draft RFC3552 SMTP Issues July 2005
4.4 Section 6.1.2: Communications Security
In the opinion of this author, this material is quite good. It
belongs somewhere, but probably not in the SMTP specification. For
that specification, it goes fairly far into message header issues
(normally the provence of other specifications), it explores
difficulties in other protocols, such as the use of IPSEC, and so
forth. In addition, it suffers from some of the same difficulties
discussed above in Section 4.2: if one is going to go into these
areas in the context of SMTP, some of the discussion is insufficient
and incomplete.
4.5 6.1.3: Denial of Service
Again, while there is nothing wrong with this new material, it is not
clear that it is adequate in the SMTP context. Singling out one
specific implementation for one of its idiosyncracies seems
particularly inappropriate. If one is going to examine DoS attacks
in the SMTP context, perhaps the most important issue --certainly an
important issue-- involves tuning of the various SMTP timeouts. That
is a hot topic on many discussion lists, especially those concerned
with spam fighting, and has been for years. Additionally, there are
specific, standards-track, SMTP extensions (including [5], a Full
Standard) that can be used to manage some of the issues this section
raises (in the case of RFC 1870, the excessive disk usage problem)
but are not mentioned in the discussion that RFC 3552 supplies.
Where is it appropriate for the security considerations material of
RFC 2821 us stop, given the level of detail provided in other
subsections?
4.6 Additional Material for 2821bis
Interestingly, there are a wide range of topics that might
appropropriately be covered in a security analysis of SMTP that the
RFC 3552 analysis odes not cover. They include a more comprehensive
treatment of approrpriate and inappropriate actions in dealing with
mail that is presumed to be hostile, the among and type of logging
and reporting that should be maintained for mesages that are dropped,
various authentication frameworks and the problems they do and do not
solve, and so on. The likely extent of that material again suggests
that it would be better placed in a separate "mail security analysis"
document than forced into the SMTP specification.
5. Conclusion and Recommendations
The tone and several of the requirements imposed by RFC 3552 are
dubious, especially when applied to documents describing mature and
widely-deployed protocols. For such protocols, the most likely
Klensin Expires January 9, 2006 [Page 7]
Internet-Draft RFC3552 SMTP Issues July 2005
impact of strict application of 3552 as written would be to further
discourage applicability statements, standards that consolidate prior
work (in the case of SMTP, much of it already at a full Standard
level), and documents created to raise the maturity level of the
specifications, by imposing a burdensome analysis and documentation
requirement. We have too few of such documents as it is; they should
be made more burdensome to create only after careful consideration by
the community. It is also problematic to require, as RFC 3552 can be
interpreted as requiring, that the security considerations section of
every protocol specification either contain a discussion of every
other protocol that might be used with it or point to a discussion of
that protocol that was adequate under 3552's rules. Security
analysis of collections of protocols is probably better left to
stand-alone documents that can be referred to from individual members
of the collection.
Perhaps fortunately, the IESG has apparently ignored the requirements
of RFC 3552 in a number of specifications it has approved for the
standard track subsequent to 3552's publication. Of course, that
creates a different problem, one of having procedural BCPs that are
approved by the IESG and then ignored (either globally or
selectively). It is hard to argue that such documents are BCPs at
all, and their approval is probably indicative of a systemic problem
in the IETF.
At least in this author's opinion, the discussion in RFC 3552 is
quite useful and the suggestions it makes should be given serious
consideration. The difficulties arise when its text --all of its
text-- are considered normative for other specifications, especially
specifications that describe mature and widely-deployed protocols.
Its BCP status, and the use of strong normative requirement language
from RFC 2119, certainly implies that it should be considered
normative in that way and that situation probably requires some
clarification.
6. Security Considerations
This document is about an effort to refine the specification for
security considerations sections, especially in the context of
updated descriptions for mature and widely-deployed protocols. It
does not, itself, have any impact on protocol security.
7. Acknowledgements
Thanks to Ted Hardie and a brief discussion during an Applications
Area meeting that led to the suggestion that a document like this one
was the right way to pursue this problem. Thanks also to the several
people who encouraged me to not just write off 2821bis in the light
Klensin Expires January 9, 2006 [Page 8]
Internet-Draft RFC3552 SMTP Issues July 2005
of the discovery of the provisions of 3552. And thanks especially to
Eric Rescorla for his extensive and helpful discussion of issues in
RFC 3552 and an earlier version of this document.
8. References
8.1 Normative References
[1] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[2] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
8.2 Informative References
[3] Mindel, J. and R. Slaski, "FTP-FTAM Gateway Specification",
RFC 1415, January 1993.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
for Message Size Declaration", STD 10, RFC 1870, November 1995.
[6] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30,
RFC 2505, February 1999.
[7] Klensin, J., "Simple Mail Transfer Protocol", July 2005.
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
Email: john-ietf@jck.com
Klensin Expires January 9, 2006 [Page 9]
Internet-Draft RFC3552 SMTP Issues July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin Expires January 9, 2006 [Page 10]
