[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/