Internet Engineering Task Force (IETF) S. Moonesamy
Internet Draft March 23, 2010
Intended status: Informational
Expires: September 22, 2010
Security Consideration Issues for Internet Mail
draft-moonesamy-mail-security-00.txt
Abstract
This memo discusses about security consideration issues for Internet
Mail. It should not be considered as a replacement for RFC 3552 or
Security Consideration Sections in mail standards.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 22, 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
S. Moonesamy Expires September 2010 [Page 1]
Internet Draft Security Considerations for Mail March 5, 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
S. Moonesamy Expires September 2010 [Page 2]
Internet Draft Security Considerations for Mail March 5, 2010
1. Introduction
During a discussion about security considerations [RFC3552] for
Internet Mail, the use of Internet Mail to facilitate the
distribution of hostile content was raised as an issue. It is
important to distinguish between transmission and content. The
Simple Mail Transfer Protocol [RFC5321] is used for transmission.
The Internet Message Format [RFC5322] is used for the content. Both
the transmission and the content are restricted to US-ASCII [RFC20].
There is a risk that combinations of US-ASCII control characters
could be used to affect the operation of message viewers. In the
current mail environment, the number of such "attacks" is low
compared to the amount of hostile content that requires the
delivery of 8-bit content to the message viewer.
Multipurpose Internet Mail Extensions [RFC2045][RFC2046], commonly
known as MIME, describes the mechanisms for the delivery of 8-bit
data. This document discusses about an approach where the focus
is on security considerations issues for the 8-bit content instead
of the functionality provided by the Simple Mail Transfer Protocol
(SMTP) or through SMTP service extensions for data transmission.
1.1. Comments
Given the security issues attributed to Internet Mail, comments
about this draft should be delivered to the author by postal mail.
[RFC Editor: Please remove this subsection]
2. Mail Security
Internet Mail is generally not secure. There is no inherent
authentication of the sender. This intrinsic property has
enabled people to communicate over long distances at a low cost
without constraining the sender and receiver to be connected to
the Internet at the same time.
With the introduction of media types [RFC2046], there are serious
security risks as some media types required interpreters or
external programs. The execution of any content delivered by
Internet Mail is a dangerous operation as the potential for harm
is only limited by what the user can do on the computer. It is
not obvious to the end-users that they may be allowing an unknown
person to take control of their computer.
2.1. Spoofing the Sender
It is trivial to "spoof" the sender. The sending address is usually
S. Moonesamy Expires September 2010 [Page 3]
Internet Draft Security Considerations for Mail March 5, 2010
not a reliable way to identify the author of the message. Even if
that information can be authenticated, appropriate care is
recommended as blind faith may increase the probability of other
attacks.
2.2. Content Disposition
Although automatic execution or rendering of content delivered by
Internet Mail can be disabled, that doesn't prevent manual
execution. As the saying goes, the user is the weakest link.
2.3. Misinterpreting Content
Some implementations rely on the file extension to determine the
media type. The content can be misinterpreted as being safe as it
is incorrectly assumed that the file extension is a reliable way
to identify the actual content.
2.4. Social Attacks
Social attacks or "social engineering" remains the easiest form of
attack. It is only a matter of convincing the user, whether it is
through deceit or by providing the right motivation.
Filtering out all binary (8-bit) content does not protect the user
from all attacks. Curiousity is after all a basic human trait. The
user can be led to an external source to acquire the hostile content.
3. Security Considerations
This document emphasizes that the payload can be a security issue.
That does not mean that the transmission channel is without risk.
It is important for implementers to consider what attacks are
possible, which ones are out of scope and why they are out of scope.
4. Internationalization Considerations
There is a need for people to communicate in their native language.
Some of these languages cannot be written in a Roman-derived script.
The changes to the mail specifications for full internationalization
opens the door to new security issues. Some of the issues such as
those relating to sensorial perceptions cannot be addressed at the
transport level.
5. IANA Considerations
This document does not require the IANA to take any action.
S. Moonesamy Expires September 2010 [Page 4]
Internet Draft Security Considerations for Mail March 5, 2010
6. Acknowledgements
The author would like to thank Dave Crocker, Ned Freed and John
Klensin for providing a better perspective of the mail standards
and Stephen Kent for the discussion about security issues.
7. References
7.1. Normative References
[RFC20] Cert, V., "ASCII format for Network Interchange", RFC 20,
October 1969.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for
Writing RFC Text on Security Considerations",
BCP 72, RFC 3552, July 2003.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Author's Address
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
S. Moonesamy Expires September 2010 [Page 5]