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 https://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 December 25, 2019.
+
This Internet-Draft will expire on December 26, 2019.
Copyright (c) 2019 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 (https://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.
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 has been standardized for PGP (Pretty Good Privacy) yet.
End-to-end protection for the email headers section is currently not widely implemented – neither for messages protected by means of S/MIME nor PGP. At least two variants of header protection are known to be implemented.
-
This document describes the problem statement, generic use cases (Section 4) and requirements for header protection (Section 5) Additionally it drafts possible solutions to address the challenge. However, the final solution will be determined by the IETF LAMPS WG. Finally, some best practices are collected.
+
This document describes the problem statement, generic use cases (Section 3) and requirements for header protection (Section 4) Additionally it drafts possible solutions to address the challenge. However, the final solution will be determined by the IETF LAMPS WG. Finally, some best practices are collected.
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].
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].
The LAMPS charter contains the folllowing Work Item:
+
The LAMPS charter contains the folllowing 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, we show the generic use cases that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used for which Header Protection (HP) is to be applied to.
In the following, we show the generic use cases that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used for which Header Protection (HP) is to be applied to.
The main interaction case for Header Protection (HP) is:
+
The main interaction case for Header Protection (HP) is:
1) Both peers (sending and receiving side) fully support HP
-
For backward compatibility of legacy clients – unaware of any HP – the following intermediate interactions need to be considered as well:
+
For backward compatibility of legacy clients – unaware of any HP – the following intermediate interactions need to be considered as well:
2) The sending side fully supports HP, while the receiving side does
not support any HP
@@ -642,7 +642,7 @@
(trivial case)
-
The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S/MIME since version 3.1 (cf. [RFC8551]), in the following designated as legacy HP:
+
The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S/MIME since version 3.1 (cf. [RFC8551]), in the following designated as legacy HP:
5) The sending side fully supports HP, while the receiving side
supports legacy HP only
@@ -659,22 +659,22 @@
supports legacy HP only (trivial case)
-
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.
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.
In the following 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.
In the following 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.
This subsection is listing the requirements to address use case 1) (cf. Section 4.1).
+
This subsection is listing the requirements to address use case 1) (cf. Section 3.1).
G1: Define the format for HP for all protection levels. This includes
MIME structure, Content-Type (including charset and name),
@@ -695,8 +695,8 @@ G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
GS1: Determine which Header Fields (HFs) should or must be protected
@@ -715,8 +715,8 @@ GS3: Determine which HF should not or must not be included in the
GS4: Determine which HF to not to include to any HP part (e.g. Bcc).
GR1: Determine how HF should be displayed to the user in case of
@@ -727,18 +727,18 @@ GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
particular downgrade attacks, can be detected.
BS1: Define how full HP support can be indicated to outgoing
@@ -751,17 +751,17 @@ BS3: Ensure a HP unaware receiving side easily can display the
"Subject" HF to the user.
This sub-section addresses the use cases 5) - 9) (cf. Section 4.1).
+
This sub-section addresses the use cases 5) - 9) (cf. Section 3.1).
LS1: Depending on the solution, define a means to distinguish between
forwarded messages, legacy encapsulated messages, and
@@ -772,8 +772,8 @@ LS2: The solution should be backward compatible to existing solutions
for existing solutions.
LSS1: Determine how legacy HP support can be indicated to outgoing
@@ -783,47 +783,47 @@ LSS2: Determine how legacy HP support of the receiver can be detected
or guessed.
In the following a set of Options to achieve Email Header Protection. It is expected that the IETF LAMPS WG chooses an option to update [RFC8551] wrt. Header Protection.
In the following a set of Options to achieve Email Header Protection. It is expected that the IETF LAMPS WG chooses an option to update [RFC8551] wrt. Header Protection.
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 (signing and/or encryption) it shares the protections of the message body.
-
[[ TODO: [DKG] add more information on memory hole]]
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 (signing and/or encryption) it shares the protections of the message body.
+
[[ TODO: [DKG] add more information on memory hole]]
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
-
[[ HB: Not sure this is well expressed: In option 2 the whole message is copied into the MIME body part as message/rfc822 element. ]]
-
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. Since the MIME body part header section is itself covered by the protection mechanisms (signing and/or encryption) it shares the protections of the message body.
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
+
[[ HB: Not sure this is well expressed: In option 2 the whole message is copied into the MIME body part as message/rfc822 element. ]]
+
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. Since the MIME body part header section is itself covered by the protection mechanisms (signing and/or encryption) it shares the protections of the message body.
This section outlines how the new “forwarded” Content-Type header field parameter could be defined (probabely 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 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:
+
This section outlines how the new “forwarded” Content-Type header field parameter could be defined (probabely 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 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.
[[This section needs more work. Don’t treat anything in it as unchangeable.]]
-
For a signed-only message, it is RECOMMENDED that all “outer” header fields are copied into the “inner” protected body part. 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.
-
When generating encrypted or encrypted+signed S/MIME messages which protect header fields:
+
[[This section needs more work. Don’t treat anything in it as unchangeable.]]
+
For a signed-only message, it is RECOMMENDED that all “outer” header fields are copied into the “inner” protected body part. 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.
+
When generating encrypted or encrypted+signed S/MIME messages which protect header fields:
@@ -831,46 +831,46 @@ LSR1: Determine how legacy HP support can be detected in incoming
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”/”Bcc” header fields. 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.
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 exception, e.g. Content-Language.
-
Note that the above recommendations can also negatively affect antispam processing.
-
When displaying S/MIME messages which protect header fields (whether they are signed-only, encrypted or encrypted+signed):
+
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 exception, e.g. Content-Language.
+
Note that the above recommendations can also negatively affect antispam processing.
+
When displaying S/MIME messages which protect header fields (whether they are signed-only, encrypted or encrypted+signed):
The outer headers 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.
[[TBD: describe how to recurse to find the innermost protected root body part, extract header fields from it and propogate them to the top level. This should also work for triple-wrapped messages.]]
[[TBD: describe how to recurse to find the innermost protected root body part, extract header fields from it and propogate them to the top level. This should also work for triple-wrapped messages.]]
pretty Easy privacy (pEp) [I-D.birk-pep] is working on bringing state-of-the-art automatic cryptography known from areas like TLS to electronic mail (email) communication. pEp is determined to evolve the existing standards as fundamentally and comprehensively as needed to gain easy implementation and integration, and for easy use for regular Internet users. pEp for email wants to attaining to good security practice while still retaining backward compatibility for implementations widespread.
-
To provide the required stability as a foundation for good security practice, pEp for email defines a fixed MIME structure for its innermost message structure, so to remove most attack vectors which have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
-
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 herein referenced, and further described in [I-D.marques-pep-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. The pEp message format is different compared to the S/MIME standard in that the pEp protocols propose opportunistic end-to-end security and signature, by allowing the transport of the necessary public key material along with the original messages.
-
For the purpose of allowing the insertion of such 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 next.
-
pEp’s proposal is strict in that it requires that the cryptographic services applied to the protected message MUST include encryption. It also mandates a fixed MIME structure for the protected message, which always MUST include a plaintext and optionally an HTML representation (if HTML is used) of the same message, and requires that all other optional elements to be eventually presented as attachments. Alternatively the whole protected message could represent in turn a wrapped pEp wrapper, which makes the message structure fully recursive on purpose (e.g., for the purpose of anonymization through onion routing).
-
For the purpose of implementing mixnet routing for email, it is foreseen to nest pEp messages recursively. A protected message can in turn contain a protected message due for forwarding. This is for the purpose to increase privacy and counter the necessary leakage of plaintext addressing in the envelope of the email.
-
The recursive nature of the pEp message format allows for the implementation of progressive disclosure of the necessary transport relevant header fields just as-needed to the next mail transport agents along the transmission path.
-
pEp has also implemented the above (in Section 6.2.1) described Content-Type property “forwarded” to distinguish between encapsulated and forwarded emails.
pretty Easy privacy (pEp) [I-D.birk-pep] is working on bringing state-of-the-art automatic cryptography known from areas like TLS to electronic mail (email) communication. pEp is determined to evolve the existing standards as fundamentally and comprehensively as needed to gain easy implementation and integration, and for easy use for regular Internet users. pEp for email wants to attaining to good security practice while still retaining backward compatibility for implementations widespread.
+
To provide the required stability as a foundation for good security practice, pEp for email defines a fixed MIME structure for its innermost message structure, so to remove most attack vectors which have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
+
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 herein referenced, and further described in [I-D.marques-pep-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. The pEp message format is different compared to the S/MIME standard in that the pEp protocols propose opportunistic end-to-end security and signature, by allowing the transport of the necessary public key material along with the original messages.
+
For the purpose of allowing the insertion of such 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 next.
+
pEp’s proposal is strict in that it requires that the cryptographic services applied to the protected message MUST include encryption. It also mandates a fixed MIME structure for the protected message, which always MUST include a plaintext and optionally an HTML representation (if HTML is used) of the same message, and requires that all other optional elements to be eventually presented as attachments. Alternatively the whole protected message could represent in turn a wrapped pEp wrapper, which makes the message structure fully recursive on purpose (e.g., for the purpose of anonymization through onion routing).
+
For the purpose of implementing mixnet routing for email, it is foreseen to nest pEp messages recursively. A protected message can in turn contain a protected message due for forwarding. This is for the purpose to increase privacy and counter the necessary leakage of plaintext addressing in the envelope of the email.
+
The recursive nature of the pEp message format allows for the implementation of progressive disclosure of the necessary transport relevant header fields just as-needed to the next mail transport agents along the transmission path.
+
pEp has also implemented the above (in Section 5.2.1) described Content-Type property “forwarded” to distinguish between encapsulated and forwarded emails.
The outer message requires a minimal set of headers to be in place for being eligible for transport. This includes the “From”, “To”, “Cc”, “Bcc”, “Subject” and “Message-ID” header fields. The protocol hereby defined also depends on the “MIME-Version”, “Content-Type”, “Content-Disposition” and eventually the “Content-Transport-Encoding” header field to be present.
-
Submission and forwarding based on SMTP carries “from” and “receivers” information out-of-band, so that the “From” and “To” header fields are not strictly necessary. Nevertheless, “From”, “Date”, and at least one destination header field is mandatory as per [RFC5322]. They SHOULD be conserved for reliability.
-
The following header fields should contain a verbatim copy of the header fields of the inner message:
+
The outer message requires a minimal set of headers to be in place for being eligible for transport. This includes the “From”, “To”, “Cc”, “Bcc”, “Subject” and “Message-ID” header fields. The protocol hereby defined also depends on the “MIME-Version”, “Content-Type”, “Content-Disposition” and eventually the “Content-Transport-Encoding” header field to be present.
+
Submission and forwarding based on SMTP carries “from” and “receivers” information out-of-band, so that the “From” and “To” header fields are not strictly necessary. Nevertheless, “From”, “Date”, and at least one destination header field is mandatory as per [RFC5322]. They SHOULD be conserved for reliability.
+
The following header fields should contain a verbatim copy of the header fields of the inner message:
@@ -880,15 +880,15 @@ LSR1: Determine how legacy HP support can be detected in incoming
Cc (*)
Bcc (*)
-
The entries with an asterisk mark (*) should only be set if also present in the original message.
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.
+
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.
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.
+
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.
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 and thus more secure.
+
The document is not defining new protocol, so it doesn’t create any new security concerns not already covered by S/MIME [RFC8551], MIME [RFC2045] and Email [RFC5322] in general.
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 and thus more secure.
-
The document is not defining new protocol, so it doesn’t create any new security concerns not already covered by S/MIME [RFC8551], MIME [RFC2045] and Email [RFC5322] in general.
Special thanks go to Krista Bennett and Volker Birk for valuable input to this draft and Hernani Marques for reviewing.
-
[[ TODO [AM]: Do we need to mention: Wei Chuang, Steve Kille, David Wilson and Robert Williams (copied from Acknowledgements section of [I-D.melnikov-lamps-header-protection] ]]
-
Special thanks to Claudio Luck who authored a predecessor of this document. Essential parts of his work have been merged into this one.
-
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.
+
Special thanks go to Krista Bennett and Volker Birk for valuable input to this draft and Hernani Marques for reviewing.
+
[[ TODO [AM]: Do we need to mention: Wei Chuang, Steve Kille, David Wilson and Robert Williams (copied from Acknowledgements section of [I-D.melnikov-lamps-header-protection] ]]
+
Special thanks to Claudio Luck who authored a predecessor of this document. Essential parts of his work have been merged into this one.
+
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.
Issues with email header protection in S/MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed.
+
The pretty Easy privacy (pEp) implementations currently use a mechanism quite similar to the currently standardized message wrapping for S/MIME. The main difference is that pEp is using PGP/MIME instead, and adds space for carrying public keys next to the protected message.
+
In LAMPS voices have also been expressed, that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME.
+
This document aims to contribute to this discussion and share pEp implementation experience with email header protection.
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 https://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 November 2, 2019.
Copyright (c) 2019 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 (https://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.
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 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 headers section and are not capable of providing privacy for the information contained therein.
+
The need for means of Data Minimization, which includes data spareness and hiding of all information, which technically can be hidden, has grown in importance over the past years.
+
A standard for end-to-end protection of the email headers section exists for S/MIME since version 3.1. (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 has been standardized for PGP (Pretty Good Privacy) yet.
+
End-to-end protection for the email headers section is currently not widely implemented – neither for messages protected by means of S/MIME nor PGP. At least two variants of header protection are known to be implemented. A recently submitted Internet-Draft [I-D.melnikov-lamps-header-protection] discusses the two variants and the challenges with header protection for S/MIME. The two variants are referred to as:
+
+
+
+
Option 1: Memory Hole
+
Option 2: Wrapping with message/rfc822 or message/global
+
+
pEp (pretty Easy privacy) [I-D.birk-pep] for email [I-D.marques-pep-email] already implements an option quite similar to Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 5, ff.). Existing implementations of pEp have also added inbound support for “Memory Hole” referred to above as Option 1, thus being able to study the differences and the implementator’s challenges.
+
Interoperability and implementation symmetry between PGP/MIME and S/MIME is planned by pEp, but still in an early stage of development.
+
This document lists generic use cases (Section 3) and requirements for header protection (Section 4) and describes progressive header disclosure as implemented in the “pEp message format version 2”. This format inherently offers header protection, and may be implemented independently by mail user agents otherwise not conforming to pEp standards (Section 5, ff.).
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].
In the examples following in this section, it is a common pattern to have a MIME encoded mail containing (“wrapping”) another signed and eventually encrypted mail. Such enclosed mails are encoded following the OpenPGP standard, which specifies an encoding called “Radix-64”, which is 7-bit transport-encoding compatible by design.
+
The Radix-64 consists of a begin and an end Armor Header Line, a stream of base64-encoded data limited to 78 characters per line plus <CR><LF>, and an encoded CRC-24 value.
+
The following is an example, with some similar lines of base64 output replaced with ellipsis:
Note that OpenPGP and MIME specifications overlap when a Radix-64 immediately precedes a MIME boundary. The <CR><LF> sequence immediately preceding a MIME boundary delimiter line is considered to be part of the delimiter in [RFC2046], 5.1. And in OpenPGP, line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit in [RFC4880], 6.2. Keeping an empty line between the end Armor Header Line and the MIME boundary line is suggested.
In the following, we show the generic use cases that need to be addressed independently of whether S/MIME, PGP/MIME or any other technology is used for which Header Protection (HP) is to be applied to.
The main interaction case for Header Protection (HP) is:
+
+1) Both peers (sending and receiving side) fully support HP
+
+
+
For backward compatibility of legacy clients – unaware of any HP – the following intermediate interactions need to be considered as well:
+
+2) The sending side fully supports HP, while the receiving side does
+ not support any HP
+
+3) The sending side does not support any HP, while the receiving
+ side fully supports HP (trivial case)
+
+4) Neither the sending side nor the receiving side supports any HP
+ (trivial case)
+
+
+
The following intermediate use cases may need to be considered as well for backward compatibility with legacy HP systems, such as S/MIME since version 3.1 (cf. [RFC8551]), in the following designated as legacy HP:
+
+5) The sending side fully supports HP, while the receiving side
+ supports legacy HP only
+
+6) The sending side supports legacy HP only, while the receiving side
+ fully supports HP
+
+7) Both peers (sending and receiving side) support legacy HP only
+
+8) The sending side supports legacy HP only, while the receiving side
+ does not support any HP
+
+9) The sending side does not support any HP, while the receiving side
+ supports legacy HP only (trivial case)
+
+
+
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.
In the following 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.
This subsection is listing the requirements to address use case 1) (cf. Section 3.1).
+
+G1: Define the format for HP for all protection levels. This includes
+ MIME structure, Content-Type (including charset and name),
+ Content-Disposition (including filename), and
+ Content-Transfer-Encoding.
+
+G2: Define how a public key should be included.
+
+G3: 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.
+
+G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
+ particular downgrade attacks, are mitigated as good as possible.
+
+
+
+GS1: Determine which Header Fields (HFs) should or must be protected
+ at least for signed only email.
+
+GS2: Determine which HFs should or must be sent in clear of an
+ encrypted email.
+
+GS3: Determine which HF should not or must not be included in the
+ visible header (for transport) of an encrypted email, with the
+ default being that whatever is not needed from GS2 is not put
+ into the unencrypted transport headers, thus fulfilling data
+ minimization requirements (including data spareness and hiding
+ of all information that technically can be hidden).
+
+GS4: Determine which HF to not to include to any HP part (e.g. Bcc).
+
+
+GR1: Determine how HF should be displayed to the user in case of
+ conflicting information between the protected and unprotected
+ headers.
+
+GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
+ particular downgrade attacks, can be detected.
+
+
+BS1: Define how full HP support can be indicated to outgoing
+ messages.
+
+BS2: Define how full HP support of the receiver can be detected or
+ guessed.
+
+BS3: Ensure a HP unaware receiving side easily can display the
+ "Subject" HF to the user.
+
+
This sub-section addresses the use cases 5) - 9) (cf. Section 3.1).
+
+LS1: Depending on the solution, define a means to distinguish between
+ forwarded messages, legacy encapsulated messages, and
+ encapsulated messages 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.
+
+
+LSS1: Determine how legacy HP support can be indicated to outgoing
+ messages.
+
+LSS2: Determine how legacy HP support of the receiver can be detected
+ or guessed.
+
+
pretty Easy privacy (pEp) is working on bringing state-of-the-art automatic cryptography known from areas like TLS to electronic mail (email) communication. pEp is determined to evolve the existing standards as fundamentally and comprehensively as needed to gain easy implementation and integration, and for easy use for regular Internet users. pEp for email wants to attaining to good security practice while still retaining backward compatibility for implementations widespread.
+
To provide the required stability as a foundation for good security practice, pEp for email defines a fixed MIME structure for its innermost message structure, so to remove most attack vectors which have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
+
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 herein referenced, and further described in [I-D.marques-pep-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. The pEp message format is different compared to the S/MIME standard in that the pEp protocols propose opportunistic end-to-end security and signature, by allowing the transport of the necessary public key material along with the original messages.
+
For the purpose of allowing the insertion of such 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 next.
+
pEp’s proposal is strict in that it requires that the cryptographic services applied to the protected message MUST include encryption. It also mandates a fixed MIME structure for the protected message, which always MUST include a plaintext and optionally an HTML representation (if HTML is used) of the same message, and requires that all other optional elements to be eventually presented as attachments. Alternatively the whole protected message could represent in turn a wrapped pEp wrapper, which makes the message structure fully recursive on purpose (e.g., for the purpose of anonymization through onion routing).
+
For the purpose of implementing mixnet routing for email, it is foreseen to nest pEp messages recursively. A protected message can in turn contain a protected message due for forwarding. This is for the purpose to increase privacy and counter the necessary leakage of plaintext addressing in the envelope of the email.
+
The recursive nature of the pEp message format allows for the implementation of progressive disclosure of the necessary transport relevant header fields just as-needed to the next mail transport agents along the transmission path.
The pEp message format version 2 is designed such that a receiving Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-compliant, still has built-in capability to properly verify the integrity of the mail, decode it and display all information of the original mail to the user. The recovered protected message is selfsufficiently described, including all protected header fields.
+
The pEp message format version 2 (as used by all the various pEp implementations, cf. Section 10) is similar to what is standardized for S/MIME in [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. 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, […].
The pEp message format requires the innermost protected message to follow a fixed MIME structure and to consist of exactly one human-readable message which is represented in plain or HTML format. Both plain and html entities MUST represent the same message to the user. Any attachment to the message must be laid out in a flat list. No additional multipart entities are allowed in the pEp message.
+
These restrictions permit to build mail user agents which are immune to the EFAIL attacks.
+
This message is herein further referred to as the “pEp inner message”.
+
A mail user agent wanting to follow this standard, SHOULD transform any “original message” into a “pEp inner message” for safe representation on the receiving side.
One caveat of the design is that the user interaction with message/rfc822 entities varies considerably across different mail user agents. No standard is currently available which enables MUAs to reliably determine whenever a nested message/rfc822 entity is meant to blend the containing message, or if it was effectively intended to be forwarded as a file document. pEp currently intends to implement the proposal described by [I-D.melnikov-lamps-header-protection], 3.2, which defines a new Content-Type header field parameter with name “forwarded”, for the MUA to distinguish between a forwarded message and a nested message for the purpose of header protection, i.e., using “forwarded=no”.
With pEp message format version 2, the pEp standardized message is equally wrapped in a message/rfc822 entity, but this time being in turn wrapped in a multipart/mixed entity. The purpose of the additional nesting is to allow for public keys of the sender to be stored alongside the original message while being protected by the same mechanism.
+
For the case of PGP/MIME, the currently only implemented MIME encryption protocol implemented in pEp, the top-level entity called the “outer message” MUST contain:
+
+
+
+
exactly one entity of type message/rfc822, and
+
one or more entity of type application/pgp-keys
+
+
Notes on the current pEp client implementations:
+
+
+
+
the current pEp implementation also adds a text/plain entity containing “pEp-Wrapped-Message-Info: OUTER” as first element in the MIME tree. This element is not strictly necessary, but is in place for better backwards compatibility when manually navigating the nested message structure. This is part of the study of various solutions to maximize backwards compatibility, and has been omitted from the following examples.
+
the current pEp implementation prepends “pEp-Wrapped-Message-Info: INNER<CR><LF>” to the original message body. This is an implementation detail which should be ignored, and has been omitted in the following examples.
+
the current pEp implementation may render a text/plain directly in place of the multipart/alternate, when no HTML representation was generated by the sending MUA. This is not strict according to pEp’s own specification, and is currently being investigated.
+
+
This is an example of the top-level MIME entity, before being encrypted and signed:
+
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed;
+ boundary="6b8b4567327b23c6643c986966334873"
+
+
+ --6b8b4567327b23c6643c986966334873
+ Content-Type: message/rfc822; forwarded="no"
+
+ From: John Doe <jdoe@machine.example>
+ To: Mary Smith <mary@example.net>
+ Subject: Example
+ Date: Fri, 30 Jun 2018 09:55:06 +0200
+ Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
+ X-Pep-Version: 2.0
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative;
+ boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/plain; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+ Content-Disposition: inline; filename="msg.txt"
+
+ p=E2=89=A1p for Privacy by Default.
+ -- =20
+ Sent from my p=E2=89=A1p for Android.
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/html; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+
+ p=E2=89=A1p for Privacy by Default.<br>
+ -- <br>
+ Sent from my p=E2=89=A1p for Android.<br>
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c--
+ --6b8b4567327b23c6643c986966334873
+ Content-Type: application/pgp-keys
+ Content-Disposition: attachment; filename="pEpkey.asc"
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ ...
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ --6b8b4567327b23c6643c986966334873--
+
In pEp message format 2 the “outer message” consists of a full RFC822 message with body and a minimal set of header fields, just those necessary to conform to MIME multipart standards.
+
The “outer message” should be encrypted and carry a signature according to the MIME encryption standards. The resulting message is the transport message which a root entity of type multipart/encrypted.
+
A minimal set of header fields should be set on the “transport message”, as to permit delivery, without disclosing private information.
+
The structure of the transport message may be altered in-transit, e.g. through mailing list agents, or inspection gateways.
+
Signing and encrypting a message with MIME Security with OpenPGP [RFC3156], yields a message with the following complete MIME structure, seen across the encryption layer:
The outer message requires a minimal set of headers to be in place for being eligible for transport. This includes the “From”, “To”, “Cc”, “Bcc”, “Subject” and “Message-ID” header fields. The protocol hereby defined also depends on the “MIME-Version”, “Content-Type”, “Content-Disposition” and eventually the “Content-Transport-Encoding” header field to be present.
+
Submission and forwarding based on SMTP carries “from” and “receivers” information out-of-band, so that the “From” and “To” header fields are not strictly necessary. Nevertheless, “From”, “Date”, and at least one destination header field is mandatory as per [RFC5322]. They SHOULD be conserved for reliability.
+
The following header fields should contain a verbatim copy of the header fields of the inner message:
+
+
+
+
Date
+
From
+
To
+
Cc (*)
+
Bcc (*)
+
+
The entries with an asterisk mark (*) should only be set if also present in the original message.
+
Clients which follow pEp standards MUST set the header field value for “Subject” to “=?utf-8?Q?p=E2=89=A1p?=” or “pEp”. Clients which do not adhere to all pEp standards should set the header field value of “Subject” to a descriptive stub value. An example used in practice is
+
+
+
Subject: Encrypted message
+
The following header fields MUST be initialized with proper values according to the MIME standards:
Header field values from the transport message MUST NOT be shown, when displaying the inner message, or the outer message. The inner message MUST carry all relevant header fields necessary for display.
pEp either engages in a signed-and-encrypted communication or in an unsigned plaintext communication. Inbound signatures attached to plaintext messages are duly verified but cannot enhance the perceived quality of the message in the user interface (while an invalid signature degrades the perception) [I-D.birk-pep].
The Mail User Agent may implement outgoing filtering of mails, which may veto, alter, redirect or replicate the messages. The functionality may be implemented on the mailbox server and be configurable through a well-known protocol, e.g., by means of The Sieve Mail-Filtering Language [RFC5490], or be implemented client-side, or in a combination of both.
+
A mailbox server, which is required to process the full range of possible filters, is requiring plaintext access to the header fields.
+
In an end-to-end-encryption context, which pEp enforces by default, upon first reception of the message the mailbox server is limited to see the transport- relevant headers of the outer wrapper message. A pEp client configured to trust the server (“trusted server” setting [I-D.marques-pep-email]) will later download the encrypted message, decrypt it and replace the copy on the server by the decrypted copy.
Inbound messages are expected to be delivered to the inbox while still being encrypted. At this point in time, server-side filtering can only evaluate the unprotected header fields in the wrapper message.
+
In an end-to-end-encryption context, which pEp enforces by default, the mailbox server is limited to see the transport-relevant headers of the outer wrapper message only upon first delivery. A pEp client configured to trust the server (“trusted server” setting [I-D.marques-pep-email]) will eventually download the encrypted message, decrypt it locally and replace the copy on the server by the decrypted copy. Server-side message filters SHOULD be able to detect such post-processed messages, and apply the pending filters. The client SHOULD easily reflect the post-filtered messages in the user interface.
The Mail User Agent may implement outgoing filtering of emails, which may veto, alter or replicate the email. They may also hint the MUA to store a copy in an alternate “Sent” folder.
+
Filters which veto the sending or do alter the mail or replicate it (e.g., mass-mail generators) SHOULD be completed prior to applying protection, and thus also prior to applying header protection. Redirection to alternate “Sent” folders MUST NOT be decided prior to applying protection, but MUAs MAY abide from this restriction if they implement the “trusted server” option and the option is selected for the specific mailbox server; in this case, MUAs MUST NOT allow to redirect a message to an untrusted server by these rules, to prevent information leakage to the untrusted server.
+
[[ TODO: Mention implicit filter for minimal color-rating for message replication. ]]
+
[[ TODO: How to produce key-export-mails manually this way? That is, what about non-pEp-mode? ]]
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
+
According to [RFC7942], “[…] this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit.”
The following software implementing the pEp protocols (to varying degrees) already exists:
+
+
+
+
pEp for Outlook as add-on for Microsoft Outlook, release [SRC.pepforoutlook]
+
+
pEp for Android (based on a fork of the K9 MUA), release [SRC.pepforandroid]
+
+
Enigmail/pEp as add-on for Mozilla Thunderbird, release [SRC.enigmailpep]
+
+
pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
+
+
+
pEp for Android, iOS and Outlook are provided by pEp Security, a commercial entity specializing in end-user software implementing pEp while Enigmail/pEp is pursued as community project, supported by the pEp Foundation.
+
All software is available as Free Software and published also in source form.
[[ RFC Editor: This section should be empty and is to be removed before publication. ]]
+
+
+
+
Align with specification for MIME Content-Type message/partial
We probably have issues and overlapping specifications about encoding for nested message/rfc822 entities, specified in [RFC2046]. Further study is needed to find and understand the issues.
+
+
Signed-only protection needs further study
pEp only does header protection by applying both signing and encryption. Technically it is also possible to sign, but not encrypt the protected messages. This needs further study.
+
+
+
diff --git a/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.txt b/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.txt
new file mode 100644
index 00000000..0e4d965e
--- /dev/null
+++ b/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.txt
@@ -0,0 +1,1232 @@
+
+
+
+
+Network Working Group C. Luck
+Internet-Draft pEp Foundation
+Intended status: Informational B. Hoeneisen
+Expires: November 2, 2019 Ucom.ch
+ May 01, 2019
+
+
+ pretty Easy privacy (pEp): Header Protection
+ draft-luck-lamps-pep-header-protection-02
+
+Abstract
+
+ Issues with email header protection in S/MIME have been recently
+ raised in the IETF LAMPS Working Group. The need for amendments to
+ the existing specification regarding header protection was expressed.
+
+ The pretty Easy privacy (pEp) implementations currently use a
+ mechanism quite similar to the currently standardized message
+ wrapping for S/MIME. The main difference is that pEp is using PGP/
+ MIME instead, and adds space for carrying public keys next to the
+ protected message.
+
+ In LAMPS voices have also been expressed, that whatever mechanism
+ will be chosen, it should not be limited to S/MIME, but also
+ applicable to PGP/MIME.
+
+ This document aims to contribute to this discussion and share pEp
+ implementation experience with email header protection.
+
+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 https://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 November 2, 2019.
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 1]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 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
+ (https://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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. The OpenPGP Radix-64 . . . . . . . . . . . . . . . . . . 4
+ 2.1.1. Radix-64 in the Context of MIME Messages . . . . . . 5
+ 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6
+ 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
+ 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Additional Requirements for Backward-Compatibility With
+ Legacy Clients Unaware of Header Protection . . . . . . . 8
+ 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8
+ 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8
+ 4.3. Additional Requirements for Backward-Compatibility with
+ Legacy Header Protection Systems (if supported) . . . . . 8
+ 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9
+ 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9
+ 5. Message Format for progressive header disclosure . . . . . . 9
+ 5.1. Design principles . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3. Inner message . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. Content-Type property "forwarded" . . . . . . . . . . . . 11
+ 5.5. Outer message . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.6. Transport message . . . . . . . . . . . . . . . . . . . . 14
+ 5.7. S/MIME Compatibility . . . . . . . . . . . . . . . . . . 15
+ 6. Candidate Header Fields for Header Protection . . . . . . . . 15
+ 7. Stub Outside Headers . . . . . . . . . . . . . . . . . . . . 15
+ 8. Processing Incoming Email under Progressive Header Disclosure 16
+ 8.1. Resolving Conflicting Protected and Unprotected Header
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 2]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ Fields . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.2. Processing of Signed-only Email . . . . . . . . . . . . . 16
+ 8.3. Incoming Filter Processing . . . . . . . . . . . . . . . 16
+ 8.3.1. Staged Filtering of Inbound Messages . . . . . . . . 17
+ 8.4. Outgoing Filter Processing . . . . . . . . . . . . . . . 17
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
+ 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18
+ 10.2. Current software implementing pEp . . . . . . . . . . . 18
+ 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . 19
+ 14.2. Informative References . . . . . . . . . . . . . . . . . 21
+ Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 21
+ Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 21
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
+
+1. 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 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 headers section
+ and are not capable of providing privacy for the information
+ contained therein.
+
+ The need for means of Data Minimization, which includes data
+ spareness and hiding of all information, which technically can be
+ hidden, has grown in importance over the past years.
+
+ A standard for end-to-end protection of the email headers section
+ exists for S/MIME since version 3.1. (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 has been standardized for PGP
+ (Pretty Good Privacy) yet.
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 3]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ End-to-end protection for the email headers section is currently not
+ widely implemented - neither for messages protected by means of
+ S/MIME nor PGP. At least two variants of header protection are known
+ to be implemented. A recently submitted Internet-Draft
+ [I-D.melnikov-lamps-header-protection] discusses the two variants and
+ the challenges with header protection for S/MIME. The two variants
+ are referred to as:
+
+ o Option 1: Memory Hole
+
+ o Option 2: Wrapping with message/rfc822 or message/global
+
+ pEp (pretty Easy privacy) [I-D.birk-pep] for email
+ [I-D.marques-pep-email] already implements an option quite similar to
+ Option 2, adapting the S/MIME standards to PGP/MIME (cf. Section 5,
+ ff.). Existing implementations of pEp have also added inbound
+ support for "Memory Hole" referred to above as Option 1, thus being
+ able to study the differences and the implementator's challenges.
+
+ Interoperability and implementation symmetry between PGP/MIME and
+ S/MIME is planned by pEp, but still in an early stage of development.
+
+ This document lists generic use cases (Section 3) and requirements
+ for header protection (Section 4) and describes progressive header
+ disclosure as implemented in the "pEp message format version 2".
+ This format inherently offers header protection, and may be
+ implemented independently by mail user agents otherwise not
+ conforming to pEp standards (Section 5, ff.).
+
+2. Terms
+
+ 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].
+
+ o Man-in-the-middle attack (MITM): cf. [RFC4949]
+
+2.1. The OpenPGP Radix-64
+
+ In the examples following in this section, it is a common pattern to
+ have a MIME encoded mail containing ("wrapping") another signed and
+ eventually encrypted mail. Such enclosed mails are encoded following
+ the OpenPGP standard, which specifies an encoding called "Radix-64",
+ which is 7-bit transport-encoding compatible by design.
+
+ The Radix-64 consists of a begin and an end Armor Header Line, a
+ stream of base64-encoded data limited to 78 characters per line plus
+ , and an encoded CRC-24 value.
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 4]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ The following is an example, with some similar lines of base64 output
+ replaced with ellipsis:
+
+ -----BEGIN PGP MESSAGE-----
+ hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv
+ ...
+ j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt
+ Xd9bdvHx/ReenAk/
+ =7WaL
+ -----END PGP MESSAGE-----
+
+ To make the examples look more compact and relevant, the above will
+ be replaced symbolically by:
+
+ [[----- OpenPGP Radix-64 Block -----]]
+
+2.1.1. Radix-64 in the Context of MIME Messages
+
+ Note that OpenPGP and MIME specifications overlap when a Radix-64
+ immediately precedes a MIME boundary. The sequence
+ immediately preceding a MIME boundary delimiter line is considered to
+ be part of the delimiter in [RFC2046], 5.1. And in OpenPGP, line
+ endings are considered a part of the Armor Header Line for the
+ purposes of determining the content they delimit in [RFC4880], 6.2.
+ Keeping an empty line between the end Armor Header Line and the MIME
+ boundary line is suggested.
+
+3. Use Cases
+
+ In the following, we show the generic use cases that need to be
+ addressed independently of whether S/MIME, PGP/MIME or any other
+ technology is used for which Header Protection (HP) is to be applied
+ to.
+
+3.1. Interactions
+
+ The main interaction case for Header Protection (HP) is:
+
+ 1) Both peers (sending and receiving side) fully support HP
+
+
+ For backward compatibility of legacy clients - unaware of any HP -
+ the following intermediate interactions need to be considered as
+ well:
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 5]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ 2) The sending side fully supports HP, while the receiving side does
+ not support any HP
+
+ 3) The sending side does not support any HP, while the receiving
+ side fully supports HP (trivial case)
+
+ 4) Neither the sending side nor the receiving side supports any HP
+ (trivial case)
+
+
+ The following intermediate use cases may need to be considered as
+ well for backward compatibility with legacy HP systems, such as
+ S/MIME since version 3.1 (cf. [RFC8551]), in the following
+ designated as legacy HP:
+
+ 5) The sending side fully supports HP, while the receiving side
+ supports legacy HP only
+
+ 6) The sending side supports legacy HP only, while the receiving side
+ fully supports HP
+
+ 7) Both peers (sending and receiving side) support legacy HP only
+
+ 8) The sending side supports legacy HP only, while the receiving side
+ does not support any HP
+
+ 9) The sending side does not support any HP, while the receiving side
+ supports legacy HP only (trivial case)
+
+
+ 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.
+
+3.2. Protection Levels
+
+ The following protection levels need to be considered:
+
+ a) signature and encryption
+
+ b) signature only
+
+ c) encryption only [[ TODO: verify whether relevant ]]
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 6]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+4. Requirements
+
+ In the following 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.
+
+4.1. General Requirements
+
+ This subsection is listing the requirements to address use case 1)
+ (cf. Section 3.1).
+
+ G1: Define the format for HP for all protection levels. This includes
+ MIME structure, Content-Type (including charset and name),
+ Content-Disposition (including filename), and
+ Content-Transfer-Encoding.
+
+ G2: Define how a public key should be included.
+
+ G3: 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.
+
+ G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
+ particular downgrade attacks, are mitigated as good as possible.
+
+
+
+4.1.1. Sending Side
+
+ GS1: Determine which Header Fields (HFs) should or must be protected
+ at least for signed only email.
+
+ GS2: Determine which HFs should or must be sent in clear of an
+ encrypted email.
+
+ GS3: Determine which HF should not or must not be included in the
+ visible header (for transport) of an encrypted email, with the
+ default being that whatever is not needed from GS2 is not put
+ into the unencrypted transport headers, thus fulfilling data
+ minimization requirements (including data spareness and hiding
+ of all information that technically can be hidden).
+
+ GS4: Determine which HF to not to include to any HP part (e.g. Bcc).
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 7]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+4.1.2. Receiving Side
+
+ GR1: Determine how HF should be displayed to the user in case of
+ conflicting information between the protected and unprotected
+ headers.
+
+ GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in
+ particular downgrade attacks, can be detected.
+
+
+4.2. Additional Requirements for Backward-Compatibility With Legacy
+ Clients Unaware of Header Protection
+
+ This sub-section addresses the use cases 2) - 4) (cf. Section 3.1)
+
+ B1: Depending on the solution, define a means to distinguish between
+ forwarded messages and encapsulated messages using new HP
+ mechanism.
+
+
+4.2.1. Sending side
+
+ BS1: Define how full HP support can be indicated to outgoing
+ messages.
+
+ BS2: Define how full HP support of the receiver can be detected or
+ guessed.
+
+ BS3: Ensure a HP unaware receiving side easily can display the
+ "Subject" HF to the user.
+
+
+4.2.2. Receiving side
+
+ BR1: Define how full HP support can be detected in incoming messages.
+
+
+4.3. Additional Requirements for Backward-Compatibility with Legacy
+ Header Protection Systems (if supported)
+
+ This sub-section addresses the use cases 5) - 9) (cf. Section 3.1).
+
+
+
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 8]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ LS1: Depending on the solution, define a means to distinguish between
+ forwarded messages, legacy encapsulated messages, and
+ encapsulated messages 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.
+
+
+4.3.1. Sending Side
+
+ LSS1: Determine how legacy HP support can be indicated to outgoing
+ messages.
+
+ LSS2: Determine how legacy HP support of the receiver can be detected
+ or guessed.
+
+
+4.3.2. Receiving Side
+
+ LSR1: Determine how legacy HP support can be detected in incoming
+ messages.
+
+
+5. Message Format for progressive header disclosure
+
+5.1. Design principles
+
+ pretty Easy privacy (pEp) is working on bringing state-of-the-art
+ automatic cryptography known from areas like TLS to electronic mail
+ (email) communication. pEp is determined to evolve the existing
+ standards as fundamentally and comprehensively as needed to gain easy
+ implementation and integration, and for easy use for regular Internet
+ users. pEp for email wants to attaining to good security practice
+ while still retaining backward compatibility for implementations
+ widespread.
+
+ To provide the required stability as a foundation for good security
+ practice, pEp for email defines a fixed MIME structure for its
+ innermost message structure, so to remove most attack vectors which
+ have permitted the numerous EFAIL vulnerabilities. (TBD: ref)
+
+ 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 herein referenced, and
+ further described in [I-D.marques-pep-email], either expects to
+ transfer messages in cleartext without signature or encryption, or
+ transfer them encrypted and with enclosed signature and necessary
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 9]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ 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. The pEp message format is different compared
+ to the S/MIME standard in that the pEp protocols propose
+ opportunistic end-to-end security and signature, by allowing the
+ transport of the necessary public key material along with the
+ original messages.
+
+ For the purpose of allowing the insertion of such 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 next.
+
+ pEp's proposal is strict in that it requires that the cryptographic
+ services applied to the protected message MUST include encryption.
+ It also mandates a fixed MIME structure for the protected message,
+ which always MUST include a plaintext and optionally an HTML
+ representation (if HTML is used) of the same message, and requires
+ that all other optional elements to be eventually presented as
+ attachments. Alternatively the whole protected message could
+ represent in turn a wrapped pEp wrapper, which makes the message
+ structure fully recursive on purpose (e.g., for the purpose of
+ anonymization through onion routing).
+
+ For the purpose of implementing mixnet routing for email, it is
+ foreseen to nest pEp messages recursively. A protected message can
+ in turn contain a protected message due for forwarding. This is for
+ the purpose to increase privacy and counter the necessary leakage of
+ plaintext addressing in the envelope of the email.
+
+ The recursive nature of the pEp message format allows for the
+ implementation of progressive disclosure of the necessary transport
+ relevant header fields just as-needed to the next mail transport
+ agents along the transmission path.
+
+5.2. Compatibility
+
+ The pEp message format version 2 is designed such that a receiving
+ Mail User Agent (MUA), which is OpenPGP-compliant but not pEp-
+ compliant, still has built-in capability to properly verify the
+ integrity of the mail, decode it and display all information of the
+ original mail to the user. The recovered protected message is
+ selfsufficiently described, including all protected header fields.
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 10]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ The pEp message format version 2 (as used by all the various pEp
+ implementations, cf. Section 10) is similar to what is standardized
+ for S/MIME in [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. 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, [...].
+
+5.3. Inner message
+
+ The pEp message format requires the innermost protected message to
+ follow a fixed MIME structure and to consist of exactly one human-
+ readable message which is represented in plain or HTML format. Both
+ plain and html entities MUST represent the same message to the user.
+ Any attachment to the message must be laid out in a flat list. No
+ additional multipart entities are allowed in the pEp message.
+
+ These restrictions permit to build mail user agents which are immune
+ to the EFAIL attacks.
+
+ This message is herein further referred to as the "pEp inner
+ message".
+
+ A mail user agent wanting to follow this standard, SHOULD transform
+ any "original message" into a "pEp inner message" for safe
+ representation on the receiving side.
+
+5.4. Content-Type property "forwarded"
+
+ One caveat of the design is that the user interaction with message/
+ rfc822 entities varies considerably across different mail user
+ agents. No standard is currently available which enables MUAs to
+ reliably determine whenever a nested message/rfc822 entity is meant
+ to blend the containing message, or if it was effectively intended to
+ be forwarded as a file document. pEp currently intends to implement
+ the proposal described by [I-D.melnikov-lamps-header-protection],
+ 3.2, which defines a new Content-Type header field parameter with
+ name "forwarded", for the MUA to distinguish between a forwarded
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 11]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ message and a nested message for the purpose of header protection,
+ i.e., using "forwarded=no".
+
+5.5. Outer message
+
+ With pEp message format version 2, the pEp standardized message is
+ equally wrapped in a message/rfc822 entity, but this time being in
+ turn wrapped in a multipart/mixed entity. The purpose of the
+ additional nesting is to allow for public keys of the sender to be
+ stored alongside the original message while being protected by the
+ same mechanism.
+
+ For the case of PGP/MIME, the currently only implemented MIME
+ encryption protocol implemented in pEp, the top-level entity called
+ the "outer message" MUST contain:
+
+ o exactly one entity of type message/rfc822, and
+
+ o one or more entity of type application/pgp-keys
+
+ Notes on the current pEp client implementations:
+
+ o the current pEp implementation also adds a text/plain entity
+ containing "pEp-Wrapped-Message-Info: OUTER" as first element in
+ the MIME tree. This element is not strictly necessary, but is in
+ place for better backwards compatibility when manually navigating
+ the nested message structure. This is part of the study of
+ various solutions to maximize backwards compatibility, and has
+ been omitted from the following examples.
+
+ o the current pEp implementation prepends "pEp-Wrapped-Message-Info:
+ INNER" to the original message body. This is an
+ implementation detail which should be ignored, and has been
+ omitted in the following examples.
+
+ o the current pEp implementation may render a text/plain directly in
+ place of the multipart/alternate, when no HTML representation was
+ generated by the sending MUA. This is not strict according to
+ pEp's own specification, and is currently being investigated.
+
+ This is an example of the top-level MIME entity, before being
+ encrypted and signed:
+
+
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 12]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed;
+ boundary="6b8b4567327b23c6643c986966334873"
+
+
+ --6b8b4567327b23c6643c986966334873
+ Content-Type: message/rfc822; forwarded="no"
+
+ From: John Doe
+ To: Mary Smith
+ Subject: Example
+ Date: Fri, 30 Jun 2018 09:55:06 +0200
+ Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
+ X-Pep-Version: 2.0
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative;
+ boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/plain; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+ Content-Disposition: inline; filename="msg.txt"
+
+ p=E2=89=A1p for Privacy by Default.
+ -- =20
+ Sent from my p=E2=89=A1p for Android.
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/html; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+
+ p=E2=89=A1p for Privacy by Default.
+ --
+ Sent from my p=E2=89=A1p for Android.
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c--
+ --6b8b4567327b23c6643c986966334873
+ Content-Type: application/pgp-keys
+ Content-Disposition: attachment; filename="pEpkey.asc"
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ ...
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ --6b8b4567327b23c6643c986966334873--
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 13]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+5.6. Transport message
+
+ In pEp message format 2 the "outer message" consists of a full RFC822
+ message with body and a minimal set of header fields, just those
+ necessary to conform to MIME multipart standards.
+
+ The "outer message" should be encrypted and carry a signature
+ according to the MIME encryption standards. The resulting message is
+ the transport message which a root entity of type multipart/
+ encrypted.
+
+ A minimal set of header fields should be set on the "transport
+ message", as to permit delivery, without disclosing private
+ information.
+
+ The structure of the transport message may be altered in-transit,
+ e.g. through mailing list agents, or inspection gateways.
+
+ Signing and encrypting a message with MIME Security with OpenPGP
+ [RFC3156], yields a message with the following complete MIME
+ structure, seen across the encryption layer:
+
+ = multipart/encrypted; protocol="application/pgp-encrypted";
+ + application/pgp-encrypted [ Version: 1 ]
+ + application/octet-stream; name="msg.asc"
+ {
+ Content-Disposition: inline; filename="msg.asc";
+ }
+ |
+ [ opaque encrypted structure ]
+ |
+ { minimal headers }
+ + multipart/mixed
+ + message/rfc822; forwarded="no";
+ |
+ { protected message headers }
+ + multipart/mixed
+ + multipart/alternate
+ + text/plain
+ + text/html
+ + application/octet-stream [ attachmet_1 ]
+ + application/octet-stream [ attachmet_2 ]
+ + application/pgp-keys
+
+
+ The header fields of the sub-part of type application/octet-stream
+ SHOULD be modified to ensure that:
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 14]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ o the Content-Type header field's
+
+ * "name" parameter is set to the value "msg.asc", and
+
+ * parameter "forwarded" is set to "no", and
+
+ o the Content-Disposition header field value is set to "inline"
+
+ * and the "filename" parameter is set to "msg.asc".
+
+5.7. S/MIME Compatibility
+
+ Interoperability and implementation symmetry between PGP/MIME and
+ S/MIME is on the roadmap of pEp.
+
+6. Candidate Header Fields for Header Protection
+
+ By default, all headers of the original message SHOULD be wrapped
+ with the original message, with one exception:
+
+ o the header field "Bcc" MUST NOT be added to the protected headers.
+
+7. Stub Outside Headers
+
+ The outer message requires a minimal set of headers to be in place
+ for being eligible for transport. This includes the "From", "To",
+ "Cc", "Bcc", "Subject" and "Message-ID" header fields. The protocol
+ hereby defined also depends on the "MIME-Version", "Content-Type",
+ "Content-Disposition" and eventually the "Content-Transport-Encoding"
+ header field to be present.
+
+ Submission and forwarding based on SMTP carries "from" and
+ "receivers" information out-of-band, so that the "From" and "To"
+ header fields are not strictly necessary. Nevertheless, "From",
+ "Date", and at least one destination header field is mandatory as per
+ [RFC5322]. They SHOULD be conserved for reliability.
+
+ The following header fields should contain a verbatim copy of the
+ header fields of the inner message:
+
+ o Date
+
+ o From
+
+ o To
+
+ o Cc (*)
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 15]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ o Bcc (*)
+
+ The entries with an asterisk mark (*) should only be set if also
+ present in the original message.
+
+ Clients which follow pEp standards MUST set the header field value
+ for "Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which
+ do not adhere to all pEp standards should set the header field value
+ of "Subject" to a descriptive stub value. An example used in
+ practice is
+
+ o Subject: Encrypted message
+
+ The following header fields MUST be initialized with proper values
+ according to the MIME standards:
+
+ o Content-Type
+
+ o Content-Disposition
+
+ o Content-Transport-Encoding (if necessary)
+
+8. Processing Incoming Email under Progressive Header Disclosure
+
+ [[ TODO ]]
+
+8.1. Resolving Conflicting Protected and Unprotected Header Fields
+
+ Header field values from the transport message MUST NOT be shown,
+ when displaying the inner message, or the outer message. The inner
+ message MUST carry all relevant header fields necessary for display.
+
+8.2. Processing of Signed-only Email
+
+ pEp either engages in a signed-and-encrypted communication or in an
+ unsigned plaintext communication. Inbound signatures attached to
+ plaintext messages are duly verified but cannot enhance the perceived
+ quality of the message in the user interface (while an invalid
+ signature degrades the perception) [I-D.birk-pep].
+
+8.3. Incoming Filter Processing
+
+ The Mail User Agent may implement outgoing filtering of mails, which
+ may veto, alter, redirect or replicate the messages. The
+ functionality may be implemented on the mailbox server and be
+ configurable through a well-known protocol, e.g., by means of The
+ Sieve Mail-Filtering Language [RFC5490], or be implemented client-
+ side, or in a combination of both.
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 16]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ A mailbox server, which is required to process the full range of
+ possible filters, is requiring plaintext access to the header fields.
+
+ In an end-to-end-encryption context, which pEp enforces by default,
+ upon first reception of the message the mailbox server is limited to
+ see the transport- relevant headers of the outer wrapper message. A
+ pEp client configured to trust the server ("trusted server" setting
+ [I-D.marques-pep-email]) will later download the encrypted message,
+ decrypt it and replace the copy on the server by the decrypted copy.
+
+8.3.1. Staged Filtering of Inbound Messages
+
+ Inbound messages are expected to be delivered to the inbox while
+ still being encrypted. At this point in time, server-side filtering
+ can only evaluate the unprotected header fields in the wrapper
+ message.
+
+ In an end-to-end-encryption context, which pEp enforces by default,
+ the mailbox server is limited to see the transport-relevant headers
+ of the outer wrapper message only upon first delivery. A pEp client
+ configured to trust the server ("trusted server" setting
+ [I-D.marques-pep-email]) will eventually download the encrypted
+ message, decrypt it locally and replace the copy on the server by the
+ decrypted copy. Server-side message filters SHOULD be able to detect
+ such post-processed messages, and apply the pending filters. The
+ client SHOULD easily reflect the post-filtered messages in the user
+ interface.
+
+8.4. Outgoing Filter Processing
+
+ The Mail User Agent may implement outgoing filtering of emails, which
+ may veto, alter or replicate the email. They may also hint the MUA
+ to store a copy in an alternate "Sent" folder.
+
+ Filters which veto the sending or do alter the mail or replicate it
+ (e.g., mass-mail generators) SHOULD be completed prior to applying
+ protection, and thus also prior to applying header protection.
+ Redirection to alternate "Sent" folders MUST NOT be decided prior to
+ applying protection, but MUAs MAY abide from this restriction if they
+ implement the "trusted server" option and the option is selected for
+ the specific mailbox server; in this case, MUAs MUST NOT allow to
+ redirect a message to an untrusted server by these rules, to prevent
+ information leakage to the untrusted server.
+
+ [[ TODO: Mention implicit filter for minimal color-rating for message
+ replication. ]]
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 17]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ [[ TODO: How to produce key-export-mails manually this way? That is,
+ what about non-pEp-mode? ]]
+
+9. Security Considerations
+
+ [[ TODO ]]
+
+10. Implementation Status
+
+10.1. Introduction
+
+ This section records the status of known implementations of the
+ protocol defined by this specification at the time of posting of this
+ Internet-Draft, and is based on a proposal described in [RFC7942].
+ The description of implementations in this section is intended to
+ assist the IETF in its decision processes in progressing drafts to
+ RFCs. Please note that the listing of any individual implementation
+ here does not imply endorsement by the IETF. Furthermore, no effort
+ has been spent to verify the information presented here that was
+ supplied by IETF contributors. This is not intended as, and must not
+ be construed to be, a catalog of available implementations or their
+ features. Readers are advised to note that other implementations may
+ exist.
+
+ According to [RFC7942], "[...] this will allow reviewers and working
+ groups to assign due consideration to documents that have the benefit
+ of running code, which may serve as evidence of valuable
+ experimentation and feedback that have made the implemented protocols
+ more mature. It is up to the individual working groups to use this
+ information as they see fit."
+
+10.2. Current software implementing pEp
+
+ The following software implementing the pEp protocols (to varying
+ degrees) already exists:
+
+ o pEp for Outlook as add-on for Microsoft Outlook, release
+ [SRC.pepforoutlook]
+
+ o pEp for Android (based on a fork of the K9 MUA), release
+ [SRC.pepforandroid]
+
+ o Enigmail/pEp as add-on for Mozilla Thunderbird, release
+ [SRC.enigmailpep]
+
+ o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 18]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ pEp for Android, iOS and Outlook are provided by pEp Security, a
+ commercial entity specializing in end-user software implementing pEp
+ while Enigmail/pEp is pursued as community project, supported by the
+ pEp Foundation.
+
+ All software is available as Free Software and published also in
+ source form.
+
+11. Privacy Considerations
+
+ [[ TODO ]]
+
+12. IANA Considerations
+
+ This document has no actions for IANA.
+
+13. Acknowledgements
+
+ Special thanks go to Krista Bennett and Volker Birk for valuable
+ input to this draft and Hernani Marques for reviewing.
+
+14. References
+
+14.1. Normative References
+
+ [I-D.birk-pep]
+ Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
+ Privacy by Default", draft-birk-pep-03 (work in progress),
+ March 2019.
+
+ [I-D.marques-pep-email]
+ Marques, H., "pretty Easy privacy (pEp): Email Formats and
+ Protocols", draft-marques-pep-email-02 (work in progress),
+ October 2018.
+
+ [I-D.melnikov-lamps-header-protection]
+ Melnikov, A., "Considerations for protecting Email header
+ with S/MIME", draft-melnikov-lamps-header-protection-00
+ (work in progress), October 2018.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ DOI 10.17487/RFC2046, November 1996,
+ .
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 19]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ .
+
+ [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
+ "MIME Security with OpenPGP", RFC 3156,
+ DOI 10.17487/RFC3156, August 2001,
+ .
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880,
+ DOI 10.17487/RFC4880, November 2007,
+ .
+
+ [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
+ FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
+ .
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ .
+
+ [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language --
+ Extensions for Checking Mailbox Status and Accessing
+ Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March
+ 2009, .
+
+ [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+ "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
+ RFC 6376, DOI 10.17487/RFC6376, September 2011,
+ .
+
+ [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
+ Authorizing Use of Domains in Email, Version 1", RFC 7208,
+ DOI 10.17487/RFC7208, April 2014,
+ .
+
+ [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
+ Message Authentication, Reporting, and Conformance
+ (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
+ .
+
+ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+ Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+ April 2019, .
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 20]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+14.2. Informative References
+
+ [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
+ Code: The Implementation Status Section", BCP 205,
+ RFC 7942, DOI 10.17487/RFC7942, July 2016,
+ .
+
+ [SRC.enigmailpep]
+ "Source code for Enigmail/pEp", March 2019,
+ .
+
+ [SRC.pepforandroid]
+ "Source code for pEp for Android", March 2019,
+ .
+
+ [SRC.pepforios]
+ "Source code for pEp for iOS", March 2019,
+ .
+
+ [SRC.pepforoutlook]
+ "Source code for pEp for Outlook", March 2019,
+ .
+
+Appendix A. Document Changelog
+
+ [[ RFC Editor: This section is to be removed before publication ]]
+
+ o draft-luck-lamps-pep-header-protection-02
+
+ * Add Privacy and IANA Considerations sections
+
+ * Added / Adjusted requirements
+
+ o draft-luck-lamps-pep-header-protection-01
+
+ * Major rewrite and update of whole document
+
+ o draft-luck-lamps-pep-header-protection-00
+
+ * Initial version
+
+Appendix B. Open Issues
+
+ [[ RFC Editor: This section should be empty and is to be removed
+ before publication. ]]
+
+ o Align with specification for MIME Content-Type message/partial
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 21]
+
+Internet-Draft pEp Header Protection May 2019
+
+
+ * We probably have issues and overlapping specifications about
+ encoding for nested message/rfc822 entities, specified in
+ [RFC2046]. Further study is needed to find and understand the
+ issues.
+
+ o Signed-only protection needs further study
+
+ * pEp only does header protection by applying both signing and
+ encryption. Technically it is also possible to sign, but not
+ encrypt the protected messages. This needs further study.
+
+Authors' Addresses
+
+ Claudio Luck
+ pEp Foundation
+ Oberer Graben 4
+ CH-8400 Winterthur
+ Switzerland
+
+ Email: claudio.luck@pep.foundation
+ URI: https://pep.foundation/
+
+
+ Bernie Hoeneisen
+ Ucom Standards Track Solutions GmbH
+ CH-8046 Zuerich
+ Switzerland
+
+ Phone: +41 44 500 52 44
+ Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
+ URI: https://ucom.ch/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luck & Hoeneisen Expires November 2, 2019 [Page 22]
diff --git a/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.xml b/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.xml
new file mode 100644
index 00000000..d2eea00f
--- /dev/null
+++ b/lamps-header-protection/archive/draft-luck-lamps-pep-header-protection-02.xml
@@ -0,0 +1,1570 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ pretty Easy privacy (pEp): Header Protection
+
+
+ pEp Foundation
+
+
+ Oberer Graben 4
+ CH-8400 Winterthur
+ Switzerland
+
+ claudio.luck@pep.foundation
+ https://pep.foundation/
+
+
+
+ Ucom Standards Track Solutions GmbH
+
+
+
+ CH-8046 Zuerich
+ Switzerland
+
+ +41 44 500 52 44
+ bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
+ https://ucom.ch/
+
+
+
+
+
+
+
+
+
+
+
+
+Issues with email header protection in S/MIME have been recently
+raised in the IETF LAMPS Working Group. The need for amendments to the
+existing specification regarding header protection was expressed.
+
+The pretty Easy privacy (pEp) implementations currently use a mechanism quite
+similar to the currently standardized message wrapping for S/MIME. The main
+difference is that pEp is using PGP/MIME instead, and adds space for carrying
+public keys next to the protected message.
+
+In LAMPS voices have also been expressed, that whatever mechanism will
+be chosen, it should not be limited to S/MIME, but also applicable to
+PGP/MIME.
+
+This document aims to contribute to this discussion and share pEp
+implementation experience with email header protection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 from the domain-level
+perspective, specifically DomainKeys Identified Mail (DKIM)
+ and Sender Policy Framework (SPF) and
+Domain-based Message Authentication, Reporting, and Conformance
+(DMARC) . These protocols, while essential to responding to
+a range of attacks on email, do not offer full end-to-end protection
+to the headers section and are not capable of providing privacy for
+the information contained therein.
+
+The need for means of Data Minimization, which includes data
+spareness and hiding of all information, which technically can be
+hidden, has grown in importance over the past years.
+
+A standard for end-to-end protection of the email headers section
+exists for S/MIME since version 3.1. (cf. ):
+
+
+ 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 has been standardized for PGP
+(Pretty Good Privacy) yet.
+
+End-to-end protection for the email headers section is currently not
+widely implemented – neither for messages protected by means of
+S/MIME nor PGP. At least two variants of header protection are known
+to be implemented. A recently submitted Internet-Draft
+ discusses the two variants
+and the challenges with header protection for S/MIME. The two variants
+are referred to as:
+
+
+ Option 1: Memory Hole
+ Option 2: Wrapping with message/rfc822 or message/global
+
+
+pEp (pretty Easy privacy) for email
+ already implements an option quite similar
+to Option 2, adapting the S/MIME standards to PGP/MIME (cf.
+, ff.). Existing
+implementations of pEp have also added inbound support for “Memory
+Hole” referred to above as Option 1, thus being able to study the
+differences and the implementator’s challenges.
+
+Interoperability and implementation symmetry between PGP/MIME and S/MIME is
+planned by pEp, but still in an early stage of development.
+
+This document lists generic use cases () and requirements for
+header protection () and describes progressive header
+disclosure as implemented in the “pEp message format version 2”. This format
+inherently offers header protection, and may be implemented independently by
+mail user agents otherwise not conforming to pEp standards
+(, ff.).
+
+
+
+
+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 .
+
+
+
+
+
+ Man-in-the-middle attack (MITM): cf.
+
+
+
+
+In the examples following in this section, it is a common pattern to
+have a MIME encoded mail containing (“wrapping”) another signed and
+eventually encrypted mail. Such enclosed mails are encoded following
+the OpenPGP standard, which specifies an encoding called “Radix-64”,
+which is 7-bit transport-encoding compatible by design.
+
+The Radix-64 consists of a begin and an end Armor Header Line, a
+stream of base64-encoded data limited to 78 characters per line plus
+<CR><LF>, and an encoded CRC-24 value.
+
+The following is an example, with some similar lines of base64 output
+replaced with ellipsis:
+
+
+
+To make the examples look more compact and relevant, the above will be
+replaced symbolically by:
+
+
+
+
+
+Note that OpenPGP and MIME specifications overlap when a Radix-64 immediately
+precedes a MIME boundary. The <CR><LF> sequence immediately preceding a
+MIME boundary delimiter line is considered to be part of the delimiter in
+, 5.1. And in OpenPGP, line endings are considered a part of the
+Armor Header Line for the purposes of determining the content they delimit in
+, 6.2. Keeping an empty line between the end Armor Header Line and
+the MIME boundary line is suggested.
+
+
+
+
+
+
+In the following, we show the generic use cases that need to be addressed
+independently of whether S/MIME, PGP/MIME or any other technology is
+used for which Header Protection (HP) is to be applied to.
+
+
+
+The main interaction case for Header Protection (HP) is:
+
+
+
+For backward compatibility of legacy clients – unaware of any HP – the
+following intermediate interactions need to be considered as well:
+
+
+
+The following intermediate use cases may need to be considered as well
+for backward compatibility with legacy HP systems, such as S/MIME
+since version 3.1 (cf. ), in the following designated as legacy
+HP:
+
+
+
+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.
+
+
+
+
+The following protection levels need to be considered:
+
+a) signature and encryption
+
+b) signature only
+
+c) encryption only [[ TODO: verify whether relevant ]]
+
+
+
+
+
+In the following 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.
+
+
+
+This subsection is listing the requirements to address use case 1)
+(cf. ).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+This sub-section addresses the use cases 2) - 4) (cf. )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+This sub-section addresses the use cases 5) - 9) (cf. ).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+pretty Easy privacy (pEp) is working on bringing state-of-the-art automatic
+cryptography known from areas like TLS to electronic mail (email)
+communication. pEp is determined to evolve the existing standards as
+fundamentally and comprehensively as needed to gain easy implementation and
+integration, and for easy use for regular Internet users. pEp for email wants
+to attaining to good security practice while still retaining backward
+compatibility for implementations widespread.
+
+To provide the required stability as a foundation for good security
+practice, pEp for email defines a fixed MIME structure for its innermost
+message structure, so to remove most attack vectors which have permitted the
+numerous EFAIL vulnerabilities. (TBD: ref)
+
+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 herein referenced, and further described
+in , 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. The pEp
+message format is different compared to the S/MIME standard in that the pEp
+protocols propose opportunistic end-to-end security and signature, by allowing
+the transport of the necessary public key material along with the original
+messages.
+
+For the purpose of allowing the insertion of such 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 next.
+
+pEp’s proposal is strict in that it requires that the cryptographic services
+applied to the protected message MUST include encryption. It also mandates a
+fixed MIME structure for the protected message, which always MUST include a
+plaintext and optionally an HTML representation (if HTML is used) of the same
+message, and requires that all other optional elements to be eventually
+presented as attachments. Alternatively the whole protected message could
+represent in turn a wrapped pEp wrapper, which makes the message structure
+fully recursive on purpose (e.g., for the purpose of anonymization through
+onion routing).
+
+For the purpose of implementing mixnet routing for email, it is foreseen to
+nest pEp messages recursively. A protected message can in turn contain a
+protected message due for forwarding. This is for the purpose to increase
+privacy and counter the necessary leakage of plaintext addressing in the
+envelope of the email.
+
+The recursive nature of the pEp message format allows for the implementation
+of progressive disclosure of the necessary transport relevant header fields
+just as-needed to the next mail transport agents along the transmission path.
+
+
+
+
+The pEp message format version 2 is designed such that a receiving Mail User
+Agent (MUA), which is OpenPGP-compliant but not pEp-compliant, still has
+built-in capability to properly verify the integrity of the mail, decode it
+and display all information of the original mail to the user. The recovered
+protected message is selfsufficiently described, including all protected
+header fields.
+
+The pEp message format version 2 (as used by all the various pEp
+implementations, cf. ) is similar to what is
+standardized for S/MIME in :
+
+
+ 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, […].
+
+
+
+
+
+
+
+The pEp message format requires the innermost protected message to follow a
+fixed MIME structure and to consist of exactly one human-readable message which
+is represented in plain or HTML format. Both plain and html entities MUST
+represent the same message to the user. Any attachment to the message must be
+laid out in a flat list. No additional multipart entities are allowed in the
+pEp message.
+
+These restrictions permit to build mail user agents which are immune to the
+EFAIL attacks.
+
+This message is herein further referred to as the “pEp inner message”.
+
+A mail user agent wanting to follow this standard, SHOULD transform any
+“original message” into a “pEp inner message” for safe representation on the
+receiving side.
+
+
+
+
+One caveat of the design is that the user interaction with message/rfc822
+entities varies considerably across different mail user agents. No standard is
+currently available which enables MUAs to reliably determine whenever a nested
+message/rfc822 entity is meant to blend the containing message, or if it was
+effectively intended to be forwarded as a file document. pEp currently intends
+to implement the proposal described by
+, 3.2, which defines a new Content-Type
+header field parameter with name “forwarded”, for the MUA to distinguish
+between a forwarded message and a nested message for the purpose of header
+protection, i.e., using “forwarded=no”.
+
+
+
+
+With pEp message format version 2, the pEp standardized message is equally
+wrapped in a message/rfc822 entity, but this time being in turn wrapped in a
+multipart/mixed entity. The purpose of the additional nesting is to allow for
+public keys of the sender to be stored alongside the original message while
+being protected by the same mechanism.
+
+For the case of PGP/MIME, the currently only implemented MIME encryption
+protocol implemented in pEp, the top-level entity called the “outer
+message” MUST contain:
+
+
+ exactly one entity of type message/rfc822, and
+ one or more entity of type application/pgp-keys
+
+
+Notes on the current pEp client implementations:
+
+
+ the current pEp implementation also adds a text/plain entity containing
+“pEp-Wrapped-Message-Info: OUTER” as first element in the MIME tree. This
+element is not strictly necessary, but is in place for better backwards
+compatibility when manually navigating the nested message structure. This is
+part of the study of various solutions to maximize backwards compatibility,
+and has been omitted from the following examples.
+ the current pEp implementation prepends “pEp-Wrapped-Message-Info:
+INNER<CR><LF>” to the original message body. This is an implementation
+detail which should be ignored, and has been omitted in the following examples.
+ the current pEp implementation may render a text/plain directly in place of
+the multipart/alternate, when no HTML representation was generated by the
+sending MUA. This is not strict according to pEp’s own specification, and is
+currently being investigated.
+
+
+
+
+This is an example of the top-level MIME entity, before being encrypted and
+signed:
+
+
+ To: Mary Smith
+ Subject: Example
+ Date: Fri, 30 Jun 2018 09:55:06 +0200
+ Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
+ X-Pep-Version: 2.0
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative;
+ boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/plain; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+ Content-Disposition: inline; filename="msg.txt"
+
+ p=E2=89=A1p for Privacy by Default.
+ -- =20
+ Sent from my p=E2=89=A1p for Android.
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c
+ Content-Type: text/html; charset="utf-8"
+ Content-Transfer-Encoding: quoted-printable
+
+ p=E2=89=A1p for Privacy by Default.
+ --
+ Sent from my p=E2=89=A1p for Android.
+
+ --29fe9d2b2d7f6a703c1bffc47c162a8c--
+ --6b8b4567327b23c6643c986966334873
+ Content-Type: application/pgp-keys
+ Content-Disposition: attachment; filename="pEpkey.asc"
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ ...
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ --6b8b4567327b23c6643c986966334873--
+]]>
+
+
+
+
+In pEp message format 2 the “outer message” consists of a full RFC822 message
+with body and a minimal set of header fields, just those necessary to conform
+to MIME multipart standards.
+
+The “outer message” should be encrypted and carry a signature according to the
+MIME encryption standards. The resulting message is the transport message
+which a root entity of type multipart/encrypted.
+
+A minimal set of header fields should be set on the “transport message”, as to
+permit delivery, without disclosing private information.
+
+The structure of the transport message may be altered in-transit, e.g. through
+mailing list agents, or inspection gateways.
+
+Signing and encrypting a message with MIME Security with OpenPGP ,
+yields a message with the following complete MIME structure, seen across the
+encryption layer:
+
+
+
+The header fields of the sub-part of type application/octet-stream SHOULD be
+modified to ensure that:
+
+
+ the Content-Type header field’s
+
+ “name” parameter is set to the value “msg.asc”, and
+ parameter “forwarded” is set to “no”, and
+
+ the Content-Disposition header field value is set to “inline”
+
+ and the “filename” parameter is set to “msg.asc”.
+
+
+
+
+
+
+Interoperability and implementation symmetry between PGP/MIME and S/MIME is on
+the roadmap of pEp.
+
+
+
+
+
+By default, all headers of the original message SHOULD be wrapped with the
+original message, with one exception:
+
+
+ the header field “Bcc” MUST NOT be added to the protected headers.
+
+
+
+
+
+The outer message requires a minimal set of headers to be in place for being
+eligible for transport. This includes the “From”, “To”, “Cc”, “Bcc”, “Subject”
+and “Message-ID” header fields. The protocol hereby defined also depends on the
+“MIME-Version”, “Content-Type”, “Content-Disposition” and eventually the
+“Content-Transport-Encoding” header field to be present.
+
+Submission and forwarding based on SMTP carries “from” and “receivers”
+information out-of-band, so that the “From” and “To” header fields are not
+strictly necessary. Nevertheless, “From”, “Date”, and at least one destination
+header field is mandatory as per . They SHOULD be conserved for
+reliability.
+
+The following header fields should contain a verbatim copy of the header
+fields of the inner message:
+
+
+ Date
+ From
+ To
+ Cc (*)
+ Bcc (*)
+
+
+The entries with an asterisk mark (*) should only be set if also present in the
+original message.
+
+Clients which follow pEp standards MUST set the header field value for
+“Subject” to “=?utf-8?Q?p=E2=89=A1p?=” or “pEp”. Clients which do not adhere
+to all pEp standards should set the header field value of “Subject” to a
+descriptive stub value. An example used in practice is
+
+
+ Subject: Encrypted message
+
+
+The following header fields MUST be initialized with proper values according
+to the MIME standards:
+
+
+ Content-Type
+ Content-Disposition
+ Content-Transport-Encoding (if necessary)
+
+
+
+
+
+[[ TODO ]]
+
+
+
+Header field values from the transport message MUST NOT be shown, when
+displaying the inner message, or the outer message. The inner message MUST
+carry all relevant header fields necessary for display.
+
+
+
+
+pEp either engages in a signed-and-encrypted communication or in an unsigned
+plaintext communication. Inbound signatures attached to plaintext messages are
+duly verified but cannot enhance the perceived quality of the message in the
+user interface (while an invalid signature degrades the perception)
+.
+
+
+
+
+The Mail User Agent may implement outgoing filtering of mails, which may veto,
+alter, redirect or replicate the messages. The functionality may be
+implemented on the mailbox server and be configurable through a well-known
+protocol, e.g., by means of The Sieve Mail-Filtering Language , or
+be implemented client-side, or in a combination of both.
+
+A mailbox server, which is required to process the full range of possible
+filters, is requiring plaintext access to the header fields.
+
+In an end-to-end-encryption context, which pEp enforces by default, upon first
+reception of the message the mailbox server is limited to see the transport-
+relevant headers of the outer wrapper message. A pEp client configured to trust
+the server (“trusted server” setting ) will later
+download the encrypted message, decrypt it and replace the copy on the server
+by the decrypted copy.
+
+
+
+Inbound messages are expected to be delivered to the inbox while still being
+encrypted. At this point in time, server-side filtering can only evaluate the
+unprotected header fields in the wrapper message.
+
+In an end-to-end-encryption context, which pEp enforces by default, the mailbox
+server is limited to see the transport-relevant headers of the outer wrapper
+message only upon first delivery. A pEp client configured to trust the server
+(“trusted server” setting ) will eventually download
+the encrypted message, decrypt it locally and replace the copy on the server
+by the decrypted copy. Server-side message filters SHOULD be able to detect
+such post-processed messages, and apply the pending filters. The client SHOULD
+easily reflect the post-filtered messages in the user interface.
+
+
+
+
+
+The Mail User Agent may implement outgoing filtering of emails, which may veto,
+alter or replicate the email. They may also hint the MUA to store a copy in an
+alternate “Sent” folder.
+
+
+
+Filters which veto the sending or do alter the mail or replicate it (e.g.,
+mass-mail generators) SHOULD be completed prior to applying protection, and
+thus also prior to applying header protection. Redirection to alternate “Sent”
+folders MUST NOT be decided prior to applying protection, but MUAs MAY abide
+from this restriction if they implement the “trusted server” option and the
+option is selected for the specific mailbox server; in this case, MUAs MUST NOT
+allow to redirect a message to an untrusted server by these rules, to prevent
+information leakage to the untrusted server.
+
+
+
+[[ TODO: Mention implicit filter for minimal color-rating for
+message replication. ]]
+
+[[ TODO: How to produce key-export-mails manually this way? That is, what
+about non-pEp-mode? ]]
+
+
+
+
+
+
+
+[[ TODO ]]
+
+
+
+
+
+
+This section records the status of known implementations of the
+protocol defined by this specification at the time of posting of this
+Internet-Draft, and is based on a proposal described in .
+The description of implementations in this section is intended to
+assist the IETF in its decision processes in progressing drafts to
+RFCs. Please note that the listing of any individual implementation
+here does not imply endorsement by the IETF. Furthermore, no effort
+has been spent to verify the information presented here that was
+supplied by IETF contributors. This is not intended as, and must not
+be construed to be, a catalog of available implementations or their
+features. Readers are advised to note that other implementations may
+exist.
+
+According to , “[…] this will allow reviewers and
+working groups to assign due consideration to documents that have the
+benefit of running code, which may serve as evidence of valuable
+experimentation and feedback that have made the implemented protocols
+more mature. It is up to the individual working groups to use this
+information as they see fit.”
+
+
+
+
+The following software implementing the pEp protocols (to varying
+degrees) already exists:
+
+
+ pEp for Outlook as add-on for Microsoft Outlook, release
+ pEp for Android (based on a fork of the K9 MUA), release
+ Enigmail/pEp as add-on for Mozilla Thunderbird, release
+ pEp for iOS (implemented in a new MUA), beta
+
+
+pEp for Android, iOS and Outlook are provided by pEp Security, a commercial
+entity specializing in end-user software implementing pEp while Enigmail/pEp
+is pursued as community project, supported by the pEp Foundation.
+
+All software is available as Free Software and published also in source form.
+
+
+
+
+
+[[ TODO ]]
+
+
+
+
+This document has no actions for IANA.
+
+
+
+
+Special thanks go to Krista Bennett and Volker Birk for valuable input to
+this draft and Hernani Marques for reviewing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Key words for use in RFCs to Indicate Requirement Levels
+
+
+In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+
+
+
+
+
+
+
+
+
+
+Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
+
+
+
+This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+MIME Security with OpenPGP
+
+
+
+
+
+This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+Internet Security Glossary, Version 2
+
+
+This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.
+
+
+
+
+
+
+
+
+
+
+Internet Message Format
+
+
+This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+OpenPGP Message Format
+
+
+
+
+
+
+This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata
+
+
+This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+DomainKeys Identified Mail (DKIM) Signatures
+
+
+
+
+DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]
+
+
+
+
+
+
+
+
+
+
+Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
+
+
+Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.This document obsoletes RFC 4408.
+
+
+
+
+
+
+
+
+
+Domain-based Message Authentication, Reporting, and Conformance (DMARC)
+
+
+
+Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.
+
+
+
+
+
+
+
+
+
+Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
+
+
+
+
+This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.
+
+
+
+
+
+
+
+
+
+Considerations for protecting Email header with S/MIME
+
+
+
+
+
+
+
+This document describes best practices for handling of Email header protected by S/MIME. Procedures described in this document are also applicable to OpenPGP.
+
+
+
+
+
+
+
+
+
+
+
+pretty Easy privacy (pEp): Privacy by Default
+
+
+
+
+
+
+
+
+
+
+
+The pretty Easy privacy (pEp) protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure end-to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). pEp also introduces means to verify communication peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME), and are written with the intent to be interoperable with already widely-deployed systems in order to facilitate and ease adoption and implementation. This document outlines the general design choices and principles of pEp.
+
+
+
+
+
+
+
+
+
+
+
+pretty Easy privacy (pEp): Email Formats and Protocols
+
+
+
+
+
+
+
+The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (i.e., PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranging from key distribution to mechanisms of subject encryption. The goal of pEp for email is to automatize operations in order to make email encryption usable by a wider range of Internet users, to achieve wide application of confidentiality and privacy practices in the real world. This document defines basic operations of pEp's approach towards email and two PGP/MIME formats (pEp Email Format 1 and 2) to provide certain security guarantees. The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Improving Awareness of Running Code: The Implementation Status Section
+
+
+
+This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.
+
+
+
+
+
+
+
+
+
+ Source code for pEp for Android
+
+
+
+
+
+
+
+
+ Source code for pEp for iOS
+
+
+
+
+
+
+
+
+ Source code for pEp for Outlook
+
+
+
+
+
+
+
+
+ Source code for Enigmail/pEp
+
+
+
+
+
+
+
+
+
+
+
+
+
+[[ RFC Editor: This section is to be removed before publication ]]
+
+
+ draft-luck-lamps-pep-header-protection-02
+
+ Add Privacy and IANA Considerations sections
+ Added / Adjusted requirements
+
+ draft-luck-lamps-pep-header-protection-01
+
+ Major rewrite and update of whole document
+
+ draft-luck-lamps-pep-header-protection-00
+
+ Initial version
+
+
+
+
+
+
+[[ RFC Editor: This section should be empty and is to be removed
+ before publication. ]]
+
+
+ Align with specification for MIME Content-Type message/partial
+ We probably have issues and overlapping specifications about
+encoding for nested message/rfc822 entities, specified in
+. Further study is needed to find and understand the
+issues.
+
+ Signed-only protection needs further study
+ pEp only does header protection by applying both signing and
+encryption. Technically it is also possible to sign, but not
+encrypt the protected messages. This needs further study.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd b/lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd
index 9606834b..5544c118 100644
--- a/lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd
+++ b/lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd
@@ -3,7 +3,7 @@ coding: utf-8
title: "pretty Easy privacy (pEp): Header Protection"
abbrev: pEp Header Protection
-docname: draft-luck-lamps-pep-header-protection-02
+docname: draft-luck-lamps-pep-header-protection-03
category: info
stand_alone: yes
@@ -17,7 +17,6 @@ normative:
# RFC822:
# RFC1847:
# RFC1341:
- RFC2119:
RFC2046:
RFC3156:
# RFC3501:
@@ -129,10 +128,11 @@ mail user agents otherwise not conforming to pEp standards
({{message-format-for-progressive-header-disclosure}}, ff.).
+{::include ../shared/text-blocks/key-words-rfc2119.mkd}
-# Terms
-{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+{::include ../shared/text-blocks/terms-intro.mkd}
+
diff --git a/medup-requirements/Makefile b/medup-requirements/Makefile
index 09df05a6..b966519e 100644
--- a/medup-requirements/Makefile
+++ b/medup-requirements/Makefile
@@ -11,6 +11,7 @@ all: $(OUTPUTS)
$(DRAFT).xml: $(NAME).mkd \
../shared/author_tags/iraklis_symeonidis.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/medup-requirements/draft-symeonidis-medup-requirements.mkd b/medup-requirements/draft-symeonidis-medup-requirements.mkd
index ceca2b5c..4ebc13d6 100644
--- a/medup-requirements/draft-symeonidis-medup-requirements.mkd
+++ b/medup-requirements/draft-symeonidis-medup-requirements.mkd
@@ -14,7 +14,6 @@ author:
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
normative:
- RFC2119:
RFC4949:
RFC7435:
@@ -60,9 +59,11 @@ In MEDUP these issues are addressed based on Opportunistic Security
This document covers analysis of threats and requirements.
-# Terms
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-email/Makefile b/pep-email/Makefile
index 20d3fd9a..0379e9fe 100644
--- a/pep-email/Makefile
+++ b/pep-email/Makefile
@@ -16,6 +16,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/implementation-status.mkd \
../shared/ascii-arts/basic-msg-flow.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep-email/draft-marques-pep-email.mkd b/pep-email/draft-marques-pep-email.mkd
index 7675e8ca..589ca397 100644
--- a/pep-email/draft-marques-pep-email.mkd
+++ b/pep-email/draft-marques-pep-email.mkd
@@ -15,7 +15,6 @@ author:
#{::include ../shared/author_tags/bernie_hoeneisen.mkd}
normative:
- RFC2119:
RFC3156:
RFC4949:
RFC5322:
@@ -112,9 +111,11 @@ Additionally, it is helpful to also understand the other normatively referenced
documents, in particular {{I-D.marques-pep-handshake}} {{I-D.marques-pep-rating}}.
-# Terms
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-handshake/Makefile b/pep-handshake/Makefile
index d2eecef9..c21358fb 100644
--- a/pep-handshake/Makefile
+++ b/pep-handshake/Makefile
@@ -15,6 +15,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/isoc-btn.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep-handshake/draft-marques-pep-handshake.mkd b/pep-handshake/draft-marques-pep-handshake.mkd
index ca469c3b..d254d1fd 100644
--- a/pep-handshake/draft-marques-pep-handshake.mkd
+++ b/pep-handshake/draft-marques-pep-handshake.mkd
@@ -16,7 +16,6 @@ author:
normative:
I-D.birk-pep-trustwords:
- RFC2119:
RFC4949:
# RFC5322:
RFC7435:
@@ -105,9 +104,11 @@ messaging applications and introduces methods to easily allow
authentication.
-# Terms
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-keyreset/Makefile b/pep-keyreset/Makefile
index fc41c9e4..8acaeb47 100644
--- a/pep-keyreset/Makefile
+++ b/pep-keyreset/Makefile
@@ -14,6 +14,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/isoc-btn.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep-keyreset/draft-marques-pep-keyreset.mkd b/pep-keyreset/draft-marques-pep-keyreset.mkd
index 4f861940..d2761326 100644
--- a/pep-keyreset/draft-marques-pep-keyreset.mkd
+++ b/pep-keyreset/draft-marques-pep-keyreset.mkd
@@ -13,7 +13,6 @@ author:
{::include ../shared/author_tags/hernani_marques.mkd}
normative:
- RFC2119:
# RFC3156:
RFC4949:
# RFC5322:
@@ -50,9 +49,12 @@ TBD
\[\[ TODO \]\]
-# Terms
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-keysync/Makefile b/pep-keysync/Makefile
index 5b33b25b..850e96cd 100644
--- a/pep-keysync/Makefile
+++ b/pep-keysync/Makefile
@@ -16,6 +16,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/isoc-btn.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep-keysync/draft-hoeneisen-pep-keysync.mkd b/pep-keysync/draft-hoeneisen-pep-keysync.mkd
index afc5b13e..e8c9550b 100644
--- a/pep-keysync/draft-hoeneisen-pep-keysync.mkd
+++ b/pep-keysync/draft-hoeneisen-pep-keysync.mkd
@@ -15,7 +15,6 @@ author:
# {::include ../shared/author_tags/claudio_luck.mkd}
normative:
- RFC2119:
RFC4949:
# RFC5322:
RFC7435:
@@ -97,9 +96,11 @@ Perform the synchronization in a secure manner, so that private keys are
not leaked or exposed to theft.
-# Terms
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-rating/Makefile b/pep-rating/Makefile
index 72f22e19..ee74469b 100644
--- a/pep-rating/Makefile
+++ b/pep-rating/Makefile
@@ -15,6 +15,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/isoc-btn.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep-rating/draft-marques-pep-rating.mkd b/pep-rating/draft-marques-pep-rating.mkd
index 31a1dba9..853826aa 100644
--- a/pep-rating/draft-marques-pep-rating.mkd
+++ b/pep-rating/draft-marques-pep-rating.mkd
@@ -14,7 +14,6 @@ author:
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
normative:
- RFC2119:
RFC4949:
# RFC5322:
RFC7435:
@@ -125,9 +124,11 @@ messaging applications and introduces methods to easily allow
authentication.
-# Terms
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
{::include ../shared/text-blocks/tofu.mkd}
diff --git a/pep-trustwords/Makefile b/pep-trustwords/Makefile
index 3a93482c..f35faf49 100644
--- a/pep-trustwords/Makefile
+++ b/pep-trustwords/Makefile
@@ -15,6 +15,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/ed-keysync.mkd \
../shared/references/isoc-btn.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/mitm.mkd \
../shared/text-blocks/trustwords.mkd \
diff --git a/pep-trustwords/draft-birk-pep-trustwords.mkd b/pep-trustwords/draft-birk-pep-trustwords.mkd
index 2c09069f..701b023b 100644
--- a/pep-trustwords/draft-birk-pep-trustwords.mkd
+++ b/pep-trustwords/draft-birk-pep-trustwords.mkd
@@ -16,7 +16,6 @@ author:
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
normative:
- RFC2119:
RFC4949:
# RFC7435:
RFC8126:
@@ -101,9 +100,12 @@ contact verification in Extensible Messaging and Presence Protocol
(XMPP) {{RFC6120}}, for X.509 {{RFC3647}} certificate verification in
browsers or in block chain applications for crypto currencies.
-# Terms
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
+
+
+{::include ../shared/text-blocks/terms-intro.mkd}
+
{::include ../shared/text-blocks/handshake.mkd}
diff --git a/pep/Makefile b/pep/Makefile
index a059b3e6..57b67f40 100644
--- a/pep/Makefile
+++ b/pep/Makefile
@@ -17,6 +17,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/references/isoc-btn.mkd \
../shared/references/implementation-status.mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
+ ../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/handshake.mkd \
../shared/text-blocks/trustwords.mkd \
../shared/text-blocks/tofu.mkd \
diff --git a/pep/draft-birk-pep.mkd b/pep/draft-birk-pep.mkd
index ed550822..40757842 100644
--- a/pep/draft-birk-pep.mkd
+++ b/pep/draft-birk-pep.mkd
@@ -156,13 +156,10 @@ Registration of Trustword Lists {{I-D.birk-pep-trustwords}}.
which RFCs we rely. \]\]
-# Terms
-
-## Normative language
-
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
-## Other terms
+
+{::include ../shared/text-blocks/terms-intro.mkd}
{::include ../shared/text-blocks/handshake.mkd}
{::include ../shared/text-blocks/trustwords.mkd}
diff --git a/shared/text-blocks/key-words-rfc2119.mkd b/shared/text-blocks/key-words-rfc2119.mkd
index 619428cd..1ff33b47 100644
--- a/shared/text-blocks/key-words-rfc2119.mkd
+++ b/shared/text-blocks/key-words-rfc2119.mkd
@@ -1,3 +1,5 @@
+## Requirements Language
+
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}}.
diff --git a/shared/text-blocks/terms-intro.mkd b/shared/text-blocks/terms-intro.mkd
new file mode 100644
index 00000000..7b58262a
--- /dev/null
+++ b/shared/text-blocks/terms-intro.mkd
@@ -0,0 +1,4 @@
+## Terms
+
+The following terms are defined for the scope of this document:
+