Skip to main content

Considerations for protecting Email header with S/MIME
draft-melnikov-smime-header-signing-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Alexey Melnikov
Last updated 2014-10-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-melnikov-smime-header-signing-00
Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Informational                          October 21, 2014
Expires: April 24, 2015

         Considerations for protecting Email header with S/MIME
                 draft-melnikov-smime-header-signing-00

Abstract

   This document describes best practices for handling of Email header
   protected by S/MIME.  It also adds a new Content-Type parameter to
   help distinguish an S/MIME protected forwarded message from an S/MIME
   construct protecting message header.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 24, 2015.

Copyright Notice

   Copyright (c) 2014 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
   described in the Simplified BSD License.

Melnikov                 Expires April 24, 2015                 [Page 1]
Internet-Draft         Header signing with S/MIME           October 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Recommendations for handling of S/MIME protected header . . .   3
   4.  New Content-Type header field parameter: forwarded  . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   S/MIME [RFC5751] is typically used to protect (sign and/on encrypt)
   Email message body parts, but not header of corresponding Email
   messages.  Header fields may contain confidential information or
   information whose validity need protecting from disclosure or
   modification.  [RFC5751] describes how to protect the Email message
   header [RFC5322], by wrapping the message inside a message/rfc822
   container [RFC2045]:

      In order to protect outer, non-content-related message header
      fields (for instance, the "Subject", "To", "From", and "Cc"
      fields), the sending client MAY wrap a full MIME message in a
      message/rfc822 wrapper in order to apply S/MIME security services
      to these header fields.  It is up to the receiving client to
      decide how to present this "inner" header along with the
      unprotected "outer" header.

      When an S/MIME message is received, if the top-level protected
      MIME entity has a Content-Type of message/rfc822, it can be
      assumed that the intent was to provide header protection.  This
      entity SHOULD be presented as the top-level message, taking into
      account header merging issues as previously discussed.

   While the above advice helps in protecting message header fields, it
   doesn't provide enough guidance on what information should and should
   not be included in outer (unprotected) header and how information
   from outer and inner headers should be presented to users.  This
   document describes best UI and other practices for handling of
   messages wrapped inside message/rfc822 body parts.  The goal of this
   document is to improve interoperability and minimize damage caused by
   possible differences between inner and outer headers.

Melnikov                 Expires April 24, 2015                 [Page 2]
Internet-Draft         Header signing with S/MIME           October 2014

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Recommendations for handling of S/MIME protected header

   When generating S/MIME messages which protect header fields by
   wrapping a message inside message/rfc822 wrapper:

   1.  If a header field is being encrypted because it is sensitive, its
       value MUST NOT be included in the outer header.  If the header
       field is mandatory according to RFC 5322, a stub value (or a
       value indicating that the outer value is not to be used) is to be
       included.

   2.  The outer header SHOULD be minimal in order to avoid disclosure
       of confidential information.  It is recommended that the outer
       header only contains "Date" (set to the same value as in the
       inner header), possibly "Subject" and "To"/"Bcc" header fields.
       But note that having key header fields duplicated in the outer
       header is convenient for many message stores (e.g.  IMAP) and
       clients that can't decode S/MIME encrypted messages.  In
       particular, Subject/To/Cc/Bcc information is returned in IMAP
       ENVELOPE FETCH data item [RFC3501], which is frequently used by
       IMAP clients in order to avoid parsing message header.

   3.  The "Subject" header field value of the outer header SHOULD
       either be identical to the inner "Subject" header field value, or
       contain a clear indication that the outer value is not to be used
       for display (the inner header field value would contain the true
       value).

   Note that recommendations listed above only apply to non MIME header
   fields (header fields with names not starting with "Content-"
   prefix).

   When displaying S/MIME messages which protect header fields by
   wrapping a message inside message/rfc822 wrapper:

   1.  The outer headers might be tampered with, so a receiving client
       SHOULD ignore them.  If a header field is present in the inner
       header, only the inner header field value MUST be displayed (and
       the corresponding outer value must be ignored).  If a particular
       header field is only present in the outer header, it MAY be
       ignored (not displayed) or it MAY be displayed with a clear
       indicator that it is not trustworthy(*).

Melnikov                 Expires April 24, 2015                 [Page 3]
Internet-Draft         Header signing with S/MIME           October 2014

       (*) - the latter case only applies if the header field is not
       protected is some other way, for example by DKIM.

4.  New Content-Type header field parameter: forwarded

   This document defines a new Content-Type header field parameter
   [RFC2045] with name "forwarded".  The parameter value is case-
   insensitive and can be either "yes" or "no".  (The default value
   being "no").  The parameter is only meaningful with media type
   "message/rfc822" when used within S/MIME encrypted body parts.  The
   value "yes" means that the message nested inside message/rfc822 is a
   forwarded message and not a construct created solely to protect the
   inner header.

   Instructions in [RFC5751] describing how to protect the Email message
   header [RFC5322], by wrapping the message inside a message/rfc822
   container [RFC2045] are thus updated to read:

      In order to protect outer, non-content-related message header
      fields (for instance, the "Subject", "To", "From", and "Cc"
      fields), the sending client MAY wrap a full MIME message in a
      message/rfc822 wrapper in order to apply S/MIME security services
      to these header fields.  It is up to the receiving client to
      decide how to present this "inner" header along with the
      unprotected "outer" header.

      When an S/MIME message is received, if the top-level protected
      MIME entity has a Content-Type of message/rfc822 without the
      "forwarded" parameter or with the "forwarded" parameter set to
      "no", it can be assumed that the intent was to provide header
      protection.  This entity SHOULD be presented as the top-level
      message, taking into account header merging issues as previously
      discussed.

5.  IANA Considerations

   This document requests no action from IANA.  RFC Editor should delete
   this section before publication.

6.  Security Considerations

   This document talks about UI considerations, including security
   considerations, when processing wrapped message/rfc822 messages
   protecting header fields.  One of the goals of this document is to
   specify UI for displaying such messages which is less confusing/
   misleading and thus more secure.

Melnikov                 Expires April 24, 2015                 [Page 4]
Internet-Draft         Header signing with S/MIME           October 2014

   The document is not defining new protocol, so it doesn't create any
   new security concerns not already covered by S/MIME [RFC5751], MIME
   [RFC2045] and Email [RFC5322] in general.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

7.2.  Informative References

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

Melnikov                 Expires April 24, 2015                 [Page 5]
Internet-Draft         Header signing with S/MIME           October 2014

Appendix A.  Acknowledgements

   Thank you to Steve Kille and David Wilson for suggestions, comments
   and corrections on this document.

   David Wilson came up with the idea of defining a new Content-Type
   header field parameter to distinguish forwarded messages from inner
   header field protection constructs.

Author's Address

   Alexey Melnikov
   Isode Ltd
   14 Castle Mews
   Hampton, Middlesex  TW12 2NP
   UK

   EMail: Alexey.Melnikov@isode.com

Melnikov                 Expires April 24, 2015                 [Page 6]