INTERNET-DRAFT S. Moonesamy
Intended status: Informational
Expires: January 9, 2014
July 8, 2013
Security Consideration Issues for Internet Mail
draft-moonesamy-mail-security-01
Abstract
This memo discusses about security consideration issues for Internet
Mail. It should not be considered as a replacement for RFC 3552 or
the 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.
Copyright Notice
Copyright (c) 2013 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
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
S. Moonesamy Expires January 9, 2014 [Page 1]
Internet Draft Security Considerations for Mail July 8, 2013
described in the Simplified BSD License.
S. Moonesamy Expires January 9, 2014 [Page 2]
Internet Draft Security Considerations for Mail July 8, 2013
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 January 9, 2014 [Page 3]
Internet Draft Security Considerations for Mail July 8, 2013
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 (see Appendix A).
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 (see Appendix B).
Filtering out all binary (8-bit) content does not protect the user
from all attacks. Curiosity 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 January 9, 2014 [Page 4]
Internet Draft Security Considerations for Mail July 8, 2013
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.
S. Moonesamy Expires January 9, 2014 [Page 5]
Internet Draft Security Considerations for Mail July 8, 2013
7. References
7.1. Normative References
[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.
Appendix A: Mail attachments
In 2003 a well-known educational institution in the United States
blocked the delivery of (Windows) executable attachments. It was
mentioned that it was because the file extensions (ade, adp, bas, bat,
chm, cmd, com, cpl, crt, eml, exe, hlp, hta, inf, ins,isp, jse, lnk,
mdb, mde, msc, msi, msp, mst, pcd, pif, reg, scr, sct, shs, url, vbs,
vbe, wsf, wsh, wsc) were self-executing upon receipt by the Mail User
Agent (MUA). One of the workarounds to allow attachments to be
delivered was to compress the files. These compressed attachments
usually had a file extension of "zip" or "rar".
Once it became common to send compressed attachments, the content
filters were updated to scan these attachments for viruses. The next
workaround was to encrypt the attachment to bypass the content filters.
The user would manually open the attachment by typing in the password
that was included in the message (see Section 2.4).
Appendix B: Homoglyphs
Homoglyphs are characters which are visually similar. For example, the
digit zero ("0") and the capital letter "O" are visually similar, the
digit one ("1") and the letter "l" are visually similar.
In 2000 a domain name visually similar to the domain name of an online
S. Moonesamy Expires January 9, 2014 [Page 6]
Internet Draft Security Considerations for Mail July 8, 2013
payment service in the United States was used to entice users by sending
them a message to inform them that they received a payment.
Author's Address
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
S. Moonesamy Expires January 9, 2014 [Page 7]