p≡p I-Ds (IETF Internet-Drafts)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 

38 KiB

coding
utf-8

title: "Problem Statement and Requirements for Header Protection" abbrev: Header Protection requirements docname: draft-ietf-lamps-header-protection-requirements-02 category: info

stand_alone: yes pi: [toc, sortrefs, symrefs, comments]

author: {::include ../shared/author_tags/alexey_melnikov.mkd} {::include ../shared/author_tags/bernie_hoeneisen.mkd} #{::include ../shared/author_tags/daniel_kahn_gillmor.mkd}

normative:

RFC822:

RFC1847:

RFC1341:

RFC2045: # MIME part 1 # RFC5322: # SMTP # RFC8551: # S/MIME #

informative:

RFC8301:

RFC8463:

RFC2046:

RFC3156:

RFC3501: # IMAP # RFC4949: # Internet Security Glossary # RFC4880: # PGP #

RFC5321:

RFC5490:

RFC6376: # DKIM # RFC6532: # internationalized email headers # RFC7208: # SPF #

RFC7258:

RFC7435:

RFC7489: # DMARC #

RFC7942:

I-D.melnikov-lamps-header-protection:

I-D.birk-pep:

I-D.marques-pep-email: I-D.luck-lamps-pep-header-protection:

I-D.marques-pep-handshake:

I-D.birk-pep-trustwords:

I-D.marques-pep-rating:

--- abstract

Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S/MIME specification is likely to be updated regarding header protection.

This document describes the problem statement, generic use cases, and requirements of header protection.

--- middle

Introduction

A range of protocols for the protection of electronic mail (email) exist, which allow to assess the authenticity and integrity of the email headers section or selected header fields (HF) from the domain-level perspective, specifically DomainKeys Identified Mail (DKIM) {{RFC6376}} and Sender Policy Framework (SPF) {{RFC7208}}, and Domain-based Message Authentication, Reporting, and Conformance (DMARC) {{RFC7489}}. These protocols, while essential to responding to a range of attacks on email, do not offer full end-to-end protection to the header section and are not capable of providing privacy for the information contained therein.

The need for means of Data Minimization, which includes data sparseness and hiding all technically concealable information whenever possible, has grown in importance over the past several years.

A standard for end-to-end protection of the email header section exists for S/MIME version 3.1 and later. (cf. {{RFC8551}}):

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.

No mechanism for header protection (HP) has been standardized for PGP (Pretty Good Privacy) {{RFC4880}} yet.

Several varying implementations of end-to-end protections for email header sections exist, though the total number of such implementations appears to be rather low.

Some LAMPS WG participants expressed the opinion that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME.

This document describes the problem statement ({{problem-statement}}), generic use cases ({{use-cases}}) and requirements for Header Protection ({{requirements}}). In {{implementation-considerations}}, possible solutions to address the challenge and some best practices are collected. In any case, the final solution is to be determined by the IETF LAMPS WG.

{::include ../shared/text-blocks/key-words-rfc2119.mkd}

{::include ../shared/text-blocks/terms-intro.mkd}

  • Header Protection (HP): cryptographic protection of email Header Sections for signatures and encryption

  • Header Field (HF): cf. {{RFC5322}}

  • Header Section (HS): cf. {{RFC5322}}

{::include ../shared/text-blocks/mitm.mkd}

  • 'Signature and encryption', 'signature only' or 'encryption only' are further explained in {{protection-levels}}.

Problem Statement

The LAMPS charter contains the following Work Item:

Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages.

In the following a set of challenges to be addressed:

TODO: enhance this section, add more items to the following

Privacy

  • Data Minimization, which includes data sparseness and hiding all technically concealable information whenever possible

Security

  • MITM attacks (cf. {{RFC4949}})

Usability

  • User interaction / User experience

Interoperability

  • Interoperability with {{RFC8551}} implementations

Use Cases

In the following a list of the generic use cases that need to be addressed for messages with Header Protection (HP). These use cases apply independently of whether S/MIME, PGP/MIME or any other technology is used to achieve HP.

Interactions

The main interaction case for Header Protection (HP) is:

{::include ../shared/fence-line.mkd}

  1. Both peers (sending and receiving side) fully support HP

{::include ../shared/fence-line.mkd}

For backward compatibility of legacy clients -- unaware of any HP -- the following intermediate interactions need to be considered as well:

{::include ../shared/fence-line.mkd} 2) The sending side fully supports HP, while the receiving side does not support any HP

  1. The sending side does not support any HP, while the receiving side fully supports HP

  2. Neither the sending side nor the receiving side supports any HP (trivial case)

{::include ../shared/fence-line.mkd}

The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S/MIME version 3.1 and later (cf. {{RFC8551}}), in the following designated as legacy HP:

{::include ../shared/fence-line.mkd} 5) The sending side fully supports HP, while the receiving side supports legacy HP only

  1. The sending side supports legacy HP only, while the receiving side fully supports HP

  2. Both peers (sending and receiving side) support legacy HP only

  3. The sending side supports legacy HP only, while the receiving side does not support any HP

  4. The sending side does not support any HP, while the receiving side supports legacy HP only

{::include ../shared/fence-line.mkd}

Note: It is to be decided whether to ensure legacy HP systems do not conflict with any new solution for HP at all or whether (and to which degree) backward compatibility to legacy HP systems shall be maintained.

[[ TODO: Decide in which form legacy HP requirements should remain in this document. ]]

Protection Levels

The following protection levels need to be considered:

a) Signature and encryption

Messages containing a cryptographic signature which are also encrypted.

Sending and receiving side SHOULD implement 'signature and encryption', which is the default to use on the sending side.

b) Signature only

Messages containing a cryptographic signature, but which no encryption is applied to.

Certain implementations MAY decide to send 'signature only' messages, depending on the circumstances and customer requirements. Sending and Receiving sides SHOULD implement 'signature only'.

c) Encryption only

Messages that encryption is applied to which do not contain a cryptographic signature.

'Encryption only' is NOT RECOMMENDED on the sending side, however the receiving side needs certain guidelines on how to process received 'encrypted only' messages

Requirements

The following is a list of requirements that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used to apply HP to.

General Requirements

Note: This subsection lists the requirements to address use case 1) (cf. {{interactions}}).

{::include ../shared/fence-line.mkd}

G1: Define the HP format for all protection levels (cf. above), which includes MIME structure, Content-Type (including all parameters, such as "charset" and "name"), Content-Disposition (including all parameters, such as "filename"), and Content-Transfer-Encoding.

G2: To foster wide implementation of the new solution, it shall be easily implementable. Unless needed for maximizing protection and privacy, existing implementations shall not require substantial changes in the existing code base. In particular also MIME libraries widely used shall not need to be changed to comply with the new mechanism for HP.

G3: There SHOULD be a single format that covers all protection levels (cf. above).

[[ TODO: Should this one remain in the document?]]

G4: Ensure that man-in-the-middle attack (MITM, cf. [RFC4949]), in particular downgrade attacks, are mitigated to the greatest extent possible.

{::include ../shared/fence-line.mkd}

Sending Side

{::include ../shared/fence-line.mkd}

GS1: Determine which Header Fields (HFs) should or must be protected for 'signature only' emails at a minimum.

GS2: Determine which HFs should or must be sent in clear text (i.e., included in the outer header) for emails with (signature and) encryption applied.

GS3: Determine which HFs should not or must not be sent in clear text (i.e., not be included in the outer header) of an email with (signature and) encryption applied.

GS4: Determine which HFs to not include to any HP part (e.g. Bcc).

{::include ../shared/fence-line.mkd}

Receiving Side

{::include ../shared/fence-line.mkd}

GR1: Determine how HFs should be displayed to the user in case of conflicting information between the protected and unprotected HFs.

GR2: Ensure that man-in-the-middle attacks (MITM, cf. [RFC4949]), in particular downgrade attacks, can be detected.

GR3: Define how emails that 'encryption only' was applied to are to be treated.

{::include ../shared/fence-line.mkd}

Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection

Note: This sub-section addresses the use cases 2) - 4) (cf. {{interactions}})

{::include ../shared/fence-line.mkd}

B1: Define a means to distinguish between forwarded emails and encapsulated emails using new HP mechanism.

{::include ../shared/fence-line.mkd}

Sending side

{::include ../shared/fence-line.mkd}

BS1: Define how full HP support can be indicated to outgoing emails.

BS2: Define how full HP support of the receiver can be detected or derived.

BS3: Ensure a HP-unaware receiving side easily can display the "Subject" HF to the user.

{::include ../shared/fence-line.mkd}

Receiving side

{::include ../shared/fence-line.mkd}

BR1: Define how full HP support can be detected in incoming emails.

{::include ../shared/fence-line.mkd}

Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)

Note: This sub-section addresses the use cases 5) - 9) (cf. {{interactions}}).

{::include ../shared/fence-line.mkd}

LS1: Depending on the solution, define a means to distinguish between forwarded emails, legacy encapsulated emails, and encapsulated emails using new HP mechanism.

LS2: The solution should be backward compatible to existing solutions and aim to minimize the implementation effort to include support for existing solutions.

{::include ../shared/fence-line.mkd}

Sending Side

{::include ../shared/fence-line.mkd}

LSS1: Determine how legacy HP support can be indicated to outgoing emails.

LSS2: Determine how legacy HP support of the receiver can be detected or derived.

{::include ../shared/fence-line.mkd}

Receiving Side

{::include ../shared/fence-line.mkd}

LSR1: Determine how legacy HP support can be detected in incoming emails.

{::include ../shared/fence-line.mkd}

Security Considerations

This document talks about UI considerations, including security considerations, when processing messages protecting Header Fields. One of the goals of this document is to specify UI for displaying such messages which is less confusing/misleading for the end-user and thus more secure.

The document does not define a new protocol, and thus does not create any new security concerns not already covered by S/MIME {{RFC8551}}, MIME [RFC2045] and Email {{RFC5322}} in general.

Privacy Considerations

TODO

IANA Considerations

This document requests no action from IANA.

RFC Editor: This section may be removed before publication.

Acknowledgments

The authors would like to thank the following people who have provided helpful comments and suggestions for this document: David Wilson, Kelly Bristol, Robert Williams, Steve Kille, and Wei Chuang.

Essential parts of {{I-D.luck-lamps-pep-header-protection}} have been merged into this document. Special thanks to its author Claudio Luck. For further Acknowledgments, please refer to Acknowledgments section of {{I-D.luck-lamps-pep-header-protection}}.

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.

--- back

Implementation Considerations

[[ Note: Please be advised that this part of the document is early work-in-progress. ]]

This {{implementation-considerations}} contains additional information and considerations regarding the implementation. Although not (strictly) part of the requirements, this is useful to better understand them. Parts of the text in this {{implementation-considerations}} will likely be moved to the upcoming implementation document.

Options to Achieve Header Protection

The following are current options for addressing Email Header Protection. The IETF LAMPS WG may choose from these options in order to update {{RFC8551}}.

Option 1: Memory Hole

The Memory Hole approach works by copying the normal message header fields into the MIME header section of the top level protected body part. Since the MIME body part header section is itself covered by the protection mechanisms (signature and/or encryption) it shares the protections of the message body.

TODO: add more information on memory hole

Option 2: Wrapping with message/rfc822 or message/global

Wrapping with message/rfc822 (or message/global) works by copying the normal message header fields into the MIME header section of the top level protect body part

[[ TODO: consider rephrasing, as not only the header fields is copied, but also the content.]]

and then prepending them with "Content-Type: message/rfc822; forwarded=no\r\n" or "Content-Type: message/global; forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF (see also {{content-type-parameter-forwarded}}). Since the MIME body part header section is itself covered by the protection mechanisms (signature and/or encryption) it shares the protections of the message body.

Content-Type Parameter "forwarded"

This section outlines how the new "forwarded" Content-Type header field parameter could be defined (probably in a separate document) and how header section wrapping works:

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 "yes"). The parameter is only meaningful with media type "message/rfc822" and "message/global" {{RFC6532}} when used within S/MIME or PGP/MIME signed or encrypted body parts. The value "yes" means that the message nested inside "message/rfc822" ("message/global") is a forwarded message and not a construct created solely to protect the inner header section.

Instructions in {{RFC8551}} describing how to protect the Email message header section {{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 section along with the unprotected "outer" header section.

When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822 or message/global 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 section merging issues as previously discussed.

Option 2.1: Progressive Header Disclosure

This option is similar to Option 2 (cf. {{rfc822-wrapping}}). It also makes use the Content-Type parameter "forwarded" (cf. {{content-type-parameter-forwarded}}).

pEp for email {{I-D.marques-pep-email}} defines a fixed MIME structure for its innermost message structure. Security comes just next after privacy in pEp, for which reason the application of signatures without encryption to messages in transit is not considered purposeful. pEp for email, either expects to transfer messages in cleartext without signature or encryption, or transfer them encrypted and with enclosed signature and necessary public keys so that replies can be immediately upgraded to encrypted messages.

The pEp message format is equivalent to the S/MIME standard in ensuring header protection, in that the whole message is protected instead, by wrapping it and providing cryptographic services to the whole original message. However, for the purpose of allowing the insertion of public keys, the root entity of the protected message is thus nested once more into an additional multipart/mixed MIME entity. The current pEp proposal is for PGP/MIME, while an extension to S/MIME is also on the roadmap.

pEp has also implemented the above (in {{content-type-parameter-forwarded}}) described Content-Type parameter "forwarded" to distinguish between encapsulated and forwarded emails.

More information on progressive header disclosure can be found in {{I-D.luck-lamps-pep-header-protection}}.

Examples

Examples in subsequent sections assume that an email client is trying to protect (sign) the following initial message:

{::include ../shared/fence-line.mkd}

Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) From: "Alexey Melnikov" alexey.melnikov@example.net Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net MIME-Version: 1.0 MMHS-Primary-Precedence: 3 Subject: Meeting at my place To: somebody@example.net X-Mailer: Isode Harrier Web Server Content-Type: text/plain; charset=us-ascii

This is an important message that I don't want to be modified.

Without message header protection the corresponding signed message might look like this. (Lines prepended by "O: " are the outer header.)

O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net O: Subject: Meeting at my place O: From: "Alexey Melnikov" alexey.melnikov@example.net O: MIME-Version: 1.0 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; O: protocol="application/pkcs7-signature"; O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

This is a multipart message in MIME format. --.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Type: text/plain; charset=us-ascii

This is an important message that I don't want to be modified.

--.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature

base-64 encoded signature

--.cbe16d2a-e1a3-4220-b821-38348fc97237--

{::include ../shared/fence-line.mkd}

Option 1: Memory Hole

The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by "O: " are the outer header section. Lines prepended by "I: " are the inner header section.

{::include ../shared/fence-line.mkd}

O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net O: Subject: Meeting at my place O: From: "Alexey Melnikov" alexey.melnikov@example.net O: MIME-Version: 1.0 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; O: protocol="application/pkcs7-signature"; O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

This is a multipart message in MIME format. --.cbe16d2a-e1a3-4220-b821-38348fc97237 I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) I: From: "Alexey Melnikov" alexey.melnikov@example.net I: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net I: MIME-Version: 1.0 I: MMHS-Primary-Precedence: 3 I: Subject: Meeting at my place I: To: somebody@example.net I: X-Mailer: Isode Harrier Web Server I: Content-Type: text/plain; charset=us-ascii

This is an important message that I don't want to be modified.

--.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature

base-64 encoded signature

--.cbe16d2a-e1a3-4220-b821-38348fc97237--

{::include ../shared/fence-line.mkd}

[[ TODO (AM): HB: Not sure whether the Outer Subject HF is replaced by "Encrypted Message" (or alike). Please verify. ]]

Option 2: Wrapping with message/rfc822 or message/global

The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by "O: " are the outer header section. Lines prepended by "I: " are the inner header section. Lines prepended by "W: " are the wrapper.

{::include ../shared/fence-line.mkd}

O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net O: Subject: Meeting at my place O: From: "Alexey Melnikov" alexey.melnikov@example.net O: MIME-Version: 1.0 O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; O: protocol="application/pkcs7-signature"; O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

This is a multipart message in MIME format. --.cbe16d2a-e1a3-4220-b821-38348fc97237 W: Content-Type: message/rfc822; forwarded=no W: I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) I: From: "Alexey Melnikov" alexey.melnikov@example.net I: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net I: MIME-Version: 1.0 I: MMHS-Primary-Precedence: 3 I: Subject: Meeting at my place I: To: somebody@example.net I: X-Mailer: Isode Harrier Web Server I: Content-Type: text/plain; charset=us-ascii

This is an important message that I don't want to be modified.

--.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature

base-64 encoded signature

--.cbe16d2a-e1a3-4220-b821-38348fc97237--

{::include ../shared/fence-line.mkd}

Option 2.1 Progressive Header Disclosure

The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and encrypted payload of the application/pkcs7-mime body part. Lines prepended by "O: " are the outer header section. Lines prepended by "I: " are the inner header section. Lines prepended by "W: " are the wrapper.

The main difference compared to Option 2 is an additional multipart/mixed Content-Type containing the original message (as a whole) and the public key (of the sender).

Note: This example is derived from the pEp's PGP/MIME implementation and adjusted to the above S/MIME examples. The pEp implementations do not support S/MIME yet; therefore the following can serve no more as for illustrative purpose. Specific examples can be found in {{I-D.luck-lamps-pep-header-protection}}.

{::include ../shared/fence-line.mkd}

O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net O: Subject: Meeting at my place O: From: "Alexey Melnikov" alexey.melnikov@example.net W: MIME-Version: 1.0 W: Content-Type: multipart/mixed; W: boundary="6b8b4567327b23c6643c986966334873" W: W: --6b8b4567327b23c6643c986966334873 W: Content-Type: message/rfc822; forwarded="no" W: I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) I: Message-ID: e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net I: Subject: Meeting at my place I: From: "Alexey Melnikov" alexey.melnikov@example.net I: MIME-Version: 1.0 I: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; I: protocol="application/pkcs7-signature"; I: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

This is a multipart message in MIME format. --.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Type: text/plain; charset=us-ascii

This is an important message that I don't want to be modified.

--.cbe16d2a-e1a3-4220-b821-38348fc97237 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature

base-64 encoded signature

--.cbe16d2a-e1a3-4220-b821-38348fc97237-- W: --6b8b4567327b23c6643c986966334873 W: Content-Type: application/pgp-keys W: Content-Disposition: attachment; filename="pEpkey.asc" W: -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK----- W: W: --6b8b4567327b23c6643c986966334873--

{::include ../shared/fence-line.mkd}

Sending Side Considerations

Candidate Header Fields for Header Protection

TODO: This section is very early stage and needs more work.

For a 'signature only' (cf. {{protection-levels}}) message, it is RECOMMENDED that all "outer" header fields are identical to the "inner" protected header fields. This would mean that all header fields are signed. In this case, the "outer" header fields simply match the protected header fields. And in the case that the "outer" header fields differ, they can simply be replaced with their protected versions when displayed to the user.

[[ TODO: Decide whether "Bcc" header field should be excluded. Also verify whether this requirement applies generally or just for specific implementations. ]]

When generating S/MIME messages with applied (signature and) encryption to protect header fields:

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

  2. The outer header section SHOULD be minimal in order to avoid disclosure of confidential information. It is recommended that the outer header section only contains "Date" (set to the same value as in the inner header field, or, if the Date value is also sensitive, to Monday 9am of the same week), possibly "Subject" and "To"/"Cc" header fields. ("From", "Date", and at least one destination header field is mandatory as per {{RFC5322}}.) In particular, Keywords, In-Reply-To and References header fields SHOULD NOT be included in the outer header; "To" and "Cc" header fields should be omitted and replaced with "Bcc: undisclosed-recipients;".

    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/Date header field values are 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 section 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 typically only apply to non MIME header fields (header fields with names not starting with "Content-" prefix), but there are exceptions, e.g. Content-Language.

Note that the above recommendations can also negatively affect anti-spam processing.

Messages containing at least one recipient address in the Bcc header field may appear in up to three different variants:

  1. The message for the recipient addresses listed in To or Cc header fields, which must not include the Bcc header field neither for signature calculation nor for encryption.

  2. The message(s) sent to the recipient addresses in the Bcc header field, which depends on the implementation:

    a) One message for each recipient in the Bcc header field separately with a Bcc header field containing only the address of the recipient it is sent to

    b) The same message for each recipient in the Bcc header field with a Bcc header field containing an indication such as "Undisclosed recipients" (but no addressees)

    c) The same message for each recipient in the Bcc header field which does not include a Bcc header field (this message is identical to 1. / cf. above)

  3. The message stored in the 'Sent'-Folder of the sender, which usually contains the Bcc unchanged from the original message, i.e. with all recipient addresses.

Regarding the Bcc header field there should be no difference between the inner and the outer header section.

Receiving Side Considerations

Which Header Fields to Display to User

When displaying S/MIME messages which protect header fields (independent of which protection level 'signature and encryption', 'signature only' or 'encryption only' is applied to (cf. {{protection-levels}}):

  1. The outer header fields might be tampered with, so a receiving client SHOULD ignore them, unless they are protected in some other way(*). 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(*).

    (*) - this only applies if the header field is not protected is some other way, for example with a DKIM signature that validates and is trusted.

Mail User Agent Algorithm for deciding which version of a header field to display

[[ TODO: describe how to recurse to find the innermost protected root body part, extract header fields from it and propagate them to the top level. This should also work for triple-wrapped messages.]]

Document Changelog

RFC Editor: This section is to be removed before publication

  • draft-ietf-lamps-header-protection-requirements-00

    • Initial version
  • draft-ietf-lamps-header-protection-requirements-01

    • Moved Implementation Considerations to Appendix (HB)

    • Shortened abstract (HB)

    • Many editorial changes, e.g., replaced "content-type" with "Content-Type". (HB)

    • Added example for Option 2.1 / pEp (HB)

    • Added (short) definition of Header Protection (HB)

    • Added more information regarding Bcc (feedback IETF-105) (HB)

    • Simplified GS3 (HB)

    • Added GR3 (HB)

Open Issues

[[ RFC Editor: This section should be empty and is to be removed before publication. ]]

  • Enhance Introduction and Problem Statement sections

  • Decide in which form legacy HP requirements should remain in this document

  • Improve definitions in {{protection-levels}}

  • Should requirement G3 remain? If you consider improve / rewrite it.

  • Add more text on Memory Hole

  • Rephrase {{rfc822-wrapping}}

  • Resolve question regarding Bcc in {{candidate-header-fields}}

  • Rewrite {{candidate-header-fields}}

  • Write {{algorithm-hf-display}}

  • Correct terminology for Header(s) and Header Fields throughout the document (editorial).

    • Header: Whole Header Section of the message
    • Header Field: Part / single Line inside a Header (Section)
  • Replace "email" by "email message" as needed