@ -18,20 +18,24 @@ normative:
# RFC822:
# RFC1847:
# RFC1341:
RFC2045: # MIME part 1 #
RFC2046: # MIME part 2 #
RFC5322: # SMTP #
RFC2045: # MIME part 1 Format of Internet Message Bodies #
RFC2046: # MIME part 2 Media Types #
# RFC2047: # MIME part 3 Message Header Extensions for Non-ASCII Text #
# RFC2048: # MIME part 4 Registration Procedures #
RFC2049: # MIME part 5 Conformance Criteria #
RFC5322: # Internet Message Format #
RFC8551: # S/MIME #
I-D.ietf-lamps-header-protection-requirements:
informative:
# RFC1939: # POP3 #
# RFC8301:
# RFC8463:
RFC3156: # PGP/MIME #
# RFC3501: # IMAP #
RFC4949: # Internet Security Glossary #
# RFC4880: # OpenPGP #
# RFC5321:
RFC5321: # SMTP #
# RFC5490:
RFC6376: # DKIM #
RFC6409:
@ -127,11 +131,6 @@ mechanism is to be determined by the IETF LAMPS WG.
{::include ../shared/text-blocks/terms-intro.mkd}
> Note: To avoid ambiguity, this document does not use the terms
> "Header" or "Headers" in isolation, but instead always uses "Header
> Field" to refer to the individual field and "Header Section" to
> refer to the entire collection; cf. {{RFC5322}}.
<!-- {::include ../shared/text - blocks/handshake.mkd} -->
<!-- {::include ../shared/text - blocks/trustwords.mkd} -->
<!-- {::include ../shared/text - blocks/tofu.mkd} -->
@ -141,13 +140,22 @@ mechanism is to be determined by the IETF LAMPS WG.
* PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}})
* Message: An Email Message consisting of Header Fields
(collectively called "the Header Section of the message") followed,
optionally, by a Body; cf. {{RFC5322}}.
Note: To avoid ambiguity, this document does not use the terms
"Header" or "Headers" in isolation, but instead always uses "Header
Field" to refer to the individual field and "Header Section" to
refer to the entire collection; cf. {{RFC5322}}.
* Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning
with a field name, followed by a colon (":"), followed by a field
body (value), and terminated by CRLF; cf. {{RFC5322}}.
* Header Section (HS): The Header Section is a sequence of lines of
characters with special syntax as defined in {{RFC5322}}. It is the
(top) section of a message containing the Header Fields.
(top) section of a M essage containing the Header Fields.
* Body: The Body is simply a sequence of characters that follows the
Header Section and is separated from the Header Section by an empty
@ -169,24 +177,6 @@ mechanism is to be determined by the IETF LAMPS WG.
* Essential Header Fields (EHF): The minimum set of Header Fields an
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
* Message: An Email Message consisting of Header Hields
(collectively called "the Header Section of the message") followed,
optionally, by a Body; cf. {{RFC5322}}.
* Transport: The entity taking care of the transport of a Message
towards the receiver or from the sender.
<!-- Feedback KRB:
It's confusing to define transport as both an entity and process. I
realize that's exactly what it is, but it reads awkwardly. Suggest
"delivery", "transit", "transfer", or similar. The other uses of
"transport" are okay, just this opening sentence needs help.
-->
The Transport on the
sending side typically determines the destination recipients by
reading the To, Cc and Bcc Header Fields (of the Outer
Message). The Transport is typically implemented by an MTA (Mail
Transfer Agent).
* Header Protection (HP): cryptographic protection of email Header
Sections (or parts of it) for signatures and/or encryption
@ -204,6 +194,18 @@ mechanism is to be determined by the IETF LAMPS WG.
cryptographic signing) is applied to a message.
-->
* Protected: Protected refers to the parts of a Message where
protection measures of any Protection Level have been applied to.
* Protected Message: A Message that protection measures of any
Protection Levels have been applied to.
* Unprotected: Unprotected refers to the parts of a Message where
no protection measures of any Protection Levels have been applied to.
* Unprotected Message: A Message that no protection measures of any
Protection Levels have been applied to.
* Original Message (OrigM): The message to be protected before any
protection related processing has been applied on the sending side.
@ -215,8 +217,8 @@ mechanism is to be determined by the IETF LAMPS WG.
(cf. {{inner-msg-hf}}). The Inner Message must be the same on the
sending and the receiving side.
* Outer Message (OuterM): The Message as handed over to the Transport
or received from the Transport respectively. The Outer Message
* Outer Message (OuterM): The Message as handed over to the Submission
Entity or received from the last hop respectively. The Outer Message
normally differs on the sending and the receiving side (e.g. new
Header Fields are added by intermediary nodes).
@ -224,18 +226,21 @@ mechanism is to be determined by the IETF LAMPS WG.
at the receiving side. Typically this is the same as the Inner
Message.
* Protected: Protected refers to the parts of a message where
protection measures of any Protection Level have been applied to.
* Protected Message: A message that protection measures of any
Protection Levels have been applied to.
* Unprotected: Unprotected refers to the parts of a message where
no protection measures of any Protection Levels have been applied to.
* Unprotected Message: A message that no protection measures of any
Protection Levels have been applied to.
* Submission Entity: The entity taking care of further processing of
the Message (incl. transport towards the receiver), after protection
measures have been applied to. It typically determines the
destination recipients by reading the To, Cc and Bcc Header Fields
(of the Outer Message).
Note: The Submission Entity varies among implementations, mainly
depending on the stage, where protection measures are applied to: It
could be e.g. a Message Submission Agent (MSA) {{RFC6409}} or a Mail
Transfer Agent (MTA) using Simple Mail Transfer Protocol (SMTP)
{{RFC5321}} or another (proprietary) solution. The latter is
particularly relevant, if protection is implemented as a plugin
solution or for mixnet networks, i.e. "onion routing" for email
(e.g. {{pEp.mixnet}}).
* Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible.
@ -282,7 +287,7 @@ In the following a set of challenges to be addressed:
# Use Cases {#use-cases}
In the following, the reader can find a list of the generic use cases
that need to be addressed for m essages with Header Protection
that need to be addressed for M essages with Header Protection
(HP). These use cases apply regardless of technology (S/MIME,
PGP/MIME, etc.) used to achieve HP.
@ -290,27 +295,89 @@ PGP/MIME, etc.) used to achieve HP.
## Interactions {#interactions}
### Main Case for Header Protection
The following use cases assume that at least the sending side supports
Header Protection as specified in this document. Receiving sides that
support this specification are expected to be able to distinguish
between Messages that Header Protection -- as specified in this
document -- has been applied to and (legacy) Mail user Agents (MUAs)
not implementing this specification.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Main Use Case {#uc-ia-main-use-case}
Both peers (sending and receiving side) fully support Header
Protection as specified in this document or the receiving side is at
least compliant with the MIME specification {{RFC2045}}, ff.;
cf. {{main-use-case}}.
Both peers (sending and receiving side) (fully) support Header
Protection as specified in this document.
The main use case is specified in {{main-use-case}}.
### Backward Compatibility
<!-- explain what is not correct -->
The sending side fully supports Header Protection as specified in this
document, while the receiving side does not support the MIME
specification {{RFC2045}}, ff. correctly; see
{{backward-compatibility-use-case}}.
### Backward Compatibility Use Cases {#uc-ia-backward-compatibility-use-cases}
Regarding backwards compatibility the main distinction is based on
whether or not the receiving side conforms to MIME according to
{{RFC2046}}, ff., which in particular also includes Section 2 of
{{RFC2049}} on "MIME Conformance". In the following an excerpt of
paragraphs relevant in this context:
{::include ../shared/fence-line.mkd}
A mail user agent that is MIME-conformant MUST:
[...]
-- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in
accordance with its media type.
-- Treat any unrecognized subtypes as if they were
"application/octet-stream".
[...]
A user agent that meets the above conditions is said to be MIME-
conformant. The meaning of this phrase is that it is assumed to be
"safe" to send virtually any kind of properly-marked data to users
of such mail systems, because such systems will at least be able to
treat the data as undifferentiated binary, and will not simply
splash it onto the screen of unsuspecting users.
{::include ../shared/fence-line.mkd}
Note: The compatibility of legacy HP systems with this new solution,
and how to handle issues surrounding future maintenance for these
legacy systems, will be decided by the LAMPS WG.
#### Receiving Side MIME-Conformant {#uc-ia-bc-receiving-side-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}),
This use case is specified in {{receiving-side-mime-conformant}}.
Note: This case is expected to just work fine, if the sending side applies
specification for the main use case {{main-use-case}}.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
#### Receiving Side Not MIME-Conformant {#uc-ia-bc-receiving-side-not-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is **not** MIME-conformant according
to {{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}})
either.
This use case is specified in {{receiving-side-not-mime-conformant}}.
## Protection Levels {#protection-levels}
The following protection levels need to be considered:
@ -345,8 +412,8 @@ This section contains the specification for Header Protection in
S/MIME to update and it clarifies Section 3.1 of {{RFC8551}} (S/MIME
4.0).
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate
this specification or parts of it.
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also
incorporate this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. {{protection-levels}}):
@ -372,11 +439,19 @@ receiving side is needed.
## Main Use Case {#main-use-case}
This section applies to the Interaction (cf. {{interactions}}), where
all involved parties (sending and receiving side) implement this
specification or the receiving side is at least compliant with the
MIME specification {{RFC2045}}, ff. (For backward compatibility cases
cf. {{backward-compatibility-use-case}}).
This section applies to the main use case, where both peers (sending
and receiving side) (fully) support Header Protection as specified
herein (cf. {{uc-ia-main-use-case}}).
Note: The sending side specification of the main use case is also
applicable to the cases, where the sending side (fully) supports
Header Protection as specified herein, while the receiving side does
not support this specification, but is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
Further backward compatibility cases are defined in
{{backward-compatibility-use-cases}}.
### MIME Format {#mime-format}
@ -502,14 +577,54 @@ Unlike the option described in {{option-smime-spec}}, this option does
not use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message.
Note: More specific on Parsers (as there are two aspects here)
Before choosing this option, two issues must be assessed to ensure, no
interoperability issues result from it:
1. How current MIME parser implementations treat (non-MIME) Header
Fields, which are not the outer most MIME entity and not wrapped
into a MIME entity of media type "message", and how such messages
are rendered to the user.
{{I-D.autocrypt-lamps-protected-headers}} provides some examples for
testing this.
2. MIME-conformance, i.e. whether or not this option is (fully)
MIME-conformant {RFC2045}} ff., in particular also Section 5.1. of
{{RFC2046}} on "Multipart Media Type). In the following an excerpt
of paragraphs that may be relevant in this context:
> A body part is an entity and hence is NOT to be interpreted as
> actually being an RFC 822 message. To begin with, NO header fields
> are actually required in body parts. A body part that starts with a
> blank line, therefore, is allowed and is a body part for which all
> default values are to be assumed. In such a case, the absence of a
> Content-Type header usually indicates that the corresponding body has
> a content-type of "text/plain; charset=US-ASCII".
>
> The only header fields that have defined meaning for body parts are
> those the names of which begin with "Content-". All other header
> fields may be ignored in body parts. Although they should generally
> be retained if at all possible, they may be discarded by gateways if
> necessary. Such other fields are permitted to appear in body parts
> but must not be depended on. "X-" fields may be created for
> experimental or private purposes, with the recognition that the
> information they contain may be lost at some gateways.
>
> NOTE: The distinction between an RFC 822 message and a body part is
> subtle, but important. A gateway between Internet and X.400 mail,
> for example, must be able to tell the difference between a body part
> that contains an image and a body part that contains an encapsulated
> message, the body of which is a JPEG image. In order to represent
> the latter, the body part must have "Content-Type: message/rfc822",
> and its body (after the blank line) must be the encapsulated message,
> with its own "Content-Type: image/jpeg" header field. The use of
> similar syntax facilitates the conversion of messages to body parts,
> and vice versa, but the distinction between the two must be
> understood by implementors. (For the special case in which parts
> actually are messages, a "digest" subtype is also defined.)
Note: it is for further study, whether or not this option is (fully)
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type).
<!--
Maybe remove (as suggested by Alexey)
-->
The MIME structure of an Email message looks as follows:
@ -607,7 +722,7 @@ within any other protected part of the message:
The wrapper is a simple MIME Header Section followed by an empty line
preceding the Inner Message (inside the Outer Message Body). The media
type of the wrapper MUST be "message/RFC822" and SHOULD contain the
type of the wrapper MUST be "message/RFC822" and MUST contain the
Content-Type header field parameter "forwarded=no" as defined in
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
the Inner Message from the rest of the message.
@ -640,13 +755,9 @@ The following Header Fields are defined as the Essential Header Fields:
* Subject
<!-- if not SMTP, it is not relevant to IETF.
describe that case in a sidenote
verify 6409 is a good reference, split to RFC5322 and RFC6409
-->
Some of these Header Fields are required by the submission service
{{RFC6409}} (e.g. From, Date). Furthermore, not including certain Header
Further processing by the Submission Entity normally depends on part
of these Header Fields, e.g. From and Date HFs are required by
{{RFC5322}}. Furthermore, not including certain Header
Fields may trigger spam detection to flag the message and/or
lead to user experience (UX) issues.
@ -717,14 +828,13 @@ MAY be obfuscated. Those may be replaced by e.g.
* To: Obfuscated < anonymous @ anonymous . invalid >
<!-- define submission service as typically RFC 6409, but also propriatory implmentation exist
-->
Such implementations need to ensure that the submission service has access to
these Header Fields in clear text and is capable of processing those.
Such implementations may need to ensure that the Submission Entity has
access to the content of these Header Fields in clear text and is
capable of processing those. This is particularly relevant, if
proprietary Submission Entities are used.
A use case for obfuscation of all Outer Message Header Fields is
mixnet networks, i.e. "onion routing" for email (e.g.{{pEp.mixnet}}).
mixnet networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
Note: It is for further study to what extent Header Field obfuscation
adversely impacts spam filtering.
@ -778,10 +888,11 @@ from:
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before processing
by Transport )
* OuterM(S): Outer Message (OuterM) at sending side (before handing it
over to the Submission Entity )
* OuterM(R): Outer Message at receiving side (as received by Transport)
* OuterM(R): Outer Message at receiving side (as received by the last
hop, before decryption and/or signature verification is applied to)
* InnerM: Inner Message (that protection is applied to)
@ -816,7 +927,7 @@ Legend:
### Sending Side Message Processing {#sending-side-message-processing}
For a protected message the following steps are applied before a
message is handed over to the Transport :
message is handed over to the Submission Entity :
#### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
@ -859,7 +970,7 @@ the wrapper (as per {{RFC8551}}), and set the result to the message as
Outer Message Body.
The resulting (Outer) Message is then typically handed over to the
Transport .
Submission Entity .
\[\[ TODO: Example \]\]
@ -885,28 +996,57 @@ typically involves rendering it for the user.
Note: Further study is needed to determine whether or not the Outer
Message Header Section, as received from the Transport , is
Message Header Section, as received from the last hop , is
preserved for the user, and if so, how this is to be achieved.
## Backward Compatibility Use Case {#backward-compatibility-use-case}
## Backward Compatibility Use Cases {#backward-compatibility-use-cases}
### Receiving Side MIME-Conformant {#receiving-side-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side does not support this specification, but is
MIME-conformant according to {{RFC2045}},
ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
The sending side specification of the main use case
(cf. {#main-use-case}}) MUST ensure that receiving sides, that do not
support this specification, but are MIME-conformant according to
{{RFC2045}}, ff. can still recognize and display the Inner Message (or
rather the RUFM) in such a way as to preserve any recursive structure,
that is, displaying or offering to display the encapsulated data in
accordance with its media type (cf. {{RFC2049}}, Section 2).
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Receiving Side Not MIME-Conformant {#receiving-side-not-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side neither supports this specification and
**nor** is MIME-conformant according to {{RFC2045}}, ff.
(cf. {{uc-ia-backward-compatibility-use-cases}) and
{{uc-ia-bc-receiving-side-not-mime-conformant}}).
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
achieve backward compatibility with existing S/MIME (and PGP/MIME)
implementations that predate this specification (Legacy Display). It
mainly focuses on email clients that do not render emails using header
protection (in a user friendly manner) and may confuse the user. While
this has been observed occasionally in PGP/MIME (cf. {{RFC3156}}), the
extent of this problem with S/MIME implementations is still
unclear. (Note: At this time, none of the samples in
{{I-D.autocrypt-lamps-protected-headers}} apply header protection as
specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
Type "message/RFC822".)
implementations that predate this specification and are no t
MIME-conformant (Legacy Display) either. It mainly focuses on email clients
that do not render emails using header protection (in a user friendly
manner) and may confuse the user. While this has been observed
occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of this problem
with S/MIME implementations is still unclear. (Note: At this time,
none of the samples in {{I-D.autocrypt-lamps-protected-headers}} apply
header protection as specified in Section 3.1 of {{RFC8551}}, which is
wrapping as Media Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver be discovered, the Legacy Display format described in
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
mitigate those issues (cf. {{backward-compatibility-use-case}}).
mitigate those issues (cf. {{backward-compatibility-use-cases }}).
Another variant of backward compatibility has been implemented by pEp
{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
@ -936,7 +1076,7 @@ The authors would like to thank the following people who have provided
helpful comments and suggestions for this document: Berna Alp, Claudio
Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,
Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
Chuang. <!-- TODO: add DKG either to authors or to Acknowledg e ments
Chuang. <!-- TODO: add DKG either to authors or to Acknowledg ments
-->
--- back
@ -993,7 +1133,7 @@ the message has to be cloned and adjusted depending on the recipient.
* draft-ietf-lamps-header-protection-00
* Initial version (text partialy taken over from
* Initial version (text partiall y taken over from
{{I-D.ietf-lamps-header-protection-requirements}}
# Open Issues
@ -1002,9 +1142,8 @@ the message has to be cloned and adjusted depending on the recipient.
before publication. \]\]
* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Decide on format of obfuscated HFs, in particular Date HF
({{obfuscation-outer-HF}})
@ -1017,9 +1156,6 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Should Outer Message Header Section (as received) be preserved for
the user? ({{receiving-side-step-2}})
* Do we need to take special care of HFs that may appear multiple
times, e.g. Received HF? ({{receiving-side-step-2}})
* Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST ({{wrapper}})?
@ -1035,6 +1171,15 @@ Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Decide on whether or not specification for more legacy HP
requirements should be added to this document
* Verify ability to distinguish between Messages with Header
Protection as specified in this document and legacy clients and
update {{interactions}} accordingly.
* Verify simple backward compatibility case (Receiving Side
MIME-Conformant) is working; once solution is stable and update
paragraphs in {#uc-ia-bc-receiving-side-mime-conformant}} and
{{receiving-side-mime-conformant}} accordingly.
* Improve definitions in {{protection-levels}}
* Privacy Considerations {{privacy-considerations}}
@ -1048,10 +1193,11 @@ LocalWords: Winterthur Hoeneisen GmbH Zuerich bernhard hoeneisen rfc
LocalWords: ucom ietf melnikov birk trustwords keysync Volker ann cb
LocalWords: ISOC bnet OpenPGP pgp msg asc pEpkey MUAs UI req SMTP WG
LocalWords: UX Programme Changelog IMAP DKIM DMARC DomainKeys HB HFs
LocalWords: implementer's pkcs SignedData cryptographically LF
LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc
LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS
LocalWords: anonymization Alexey Isode ascii prepended micalg
LocalWords: sha cbe Chuang Kille cryptographic interoperability
LocalWords: roadmap
LocalWords: implementer's pkcs SignedData cryptographically LF iana
LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc KRB
LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS CRLF
LocalWords: anonymization Alexey Isode ascii prepended micalg EHF uc
LocalWords: sha cbe Chuang Kille cryptographic interoperability RUFM
LocalWords: roadmap autocrypt OrigM InnerM OuterM MSA MTA ia bc bcc
LocalWords: subtypes smime rufm HSp Berna Balicka
-->
