juga
/
internet-drafts
forked from pEp.foundation/internet-drafts
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Internal Feedback (spelling, grammar, reordering definitions, etc.), should not be content changing

Browse Source
master
Bernie Hoeneisen 3 years ago
parent 9144b13f80
commit 34a8592018
1 changed files with 110 additions and 88 deletions
Show Stats Download Patch File Download Diff File

198
misc/temp/draft-ietf-lamps-header-protection.mkd-am
Unescape View File

@ -34,6 +34,7 @@ informative:
# RFC5321:
# RFC5490:
RFC6376: # DKIM #
RFC6409:
# RFC6532: # internationalized email headers #
RFC7208: # SPF #
# RFC7258:
@ -69,7 +70,7 @@ the S/MIME specification for header protection.
# Introduction
A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the
exists, which allows to assess the authenticity and integrity of the
email headers section or selected header fields (HF) from the
domain-level perspective, specifically DomainKeys Identified Mail
(DKIM) {{RFC6376}} and Sender Policy Framework (SPF) {{RFC7208}}, and
@ -79,7 +80,7 @@ a range of attacks on email, do not offer (full) end-to-end protection
to the header section and are not capable of providing privacy for the
information contained therein.
The need for means of Data Minimization, which includes data spareness
The need for means of Data Minimization, which includes data sparseness
and hiding all technically concealable information whenever possible,
has grown in importance over the past several years.
@ -99,9 +100,13 @@ Several varying implementations of end-to-end protections for email
header sections exist, though the total number of such implementations
appears to be rather low.
Some LAMPS WG participants expressed the opinion that whatever
mechanism will be chosen, it should not be limited to S/MIME, but
also applicable to PGP/MIME.
Some LAMPS WG participants expressed the opinion that regardless of
the mechanism chosen, it should not be limited to S/MIME, but also
applicable to PGP/MIME.
<!-- Suggestion KRB:
it should be applicable to both S/MIME and PGP/MIME.
-->
This document describes the problem statement ({{problem-statement}}),
generic use cases ({{use-cases}}) and the specification for Header
@ -113,15 +118,20 @@ requirements that this specification is based on.
<!-- TODO: Decide whether to add the requirements to this document or
leave them in a separate document -->
This document is in early draft state and contains a proposal to base
the upcoming discussions on. In any case, the final solution is to be
determined by the IETF LAMPS WG.
This document is in early draft state and contains a proposal on which
to base future discussions of this topic. In any case, the final
mechanism is to be determined by the IETF LAMPS WG.
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
{::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} -->
@ -131,26 +141,10 @@ 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}}.
* Transport: The entity taking care of the transport of a Message
towards the receiver or from the sender. 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 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}}.
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 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.
@ -172,6 +166,27 @@ determined by the IETF LAMPS WG.
MIME Header Fields of a Header Section that - in addition to MIME
Header Fields - also contains non-MIME Header Fields.
* 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
@ -209,9 +224,6 @@ determined by the IETF LAMPS WG.
at the receiving side. Typically this is the same as the Inner
Message.
* Essential Header Fields (EHF): The minimum set of Header Fields an
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
* Protected: Protected refers to the parts of a message where
protection measures of any Protection Level have been applied to.
@ -224,7 +236,7 @@ determined by the IETF LAMPS WG.
* Unprotected Message: A message that no protection measures of any
Protection Levels have been applied to.
* Data Minimization: Data spareness and hiding of all technically
* Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible.
@ -247,7 +259,7 @@ In the following a set of challenges to be addressed:
## Privacy {#privacy}
* Data Minimization, which includes data spareness and hiding all
* Data Minimization, which includes data sparseness and hiding all
technically concealable information whenever possible
@ -271,9 +283,8 @@ In the following a set of challenges to be addressed:
In the following, the reader can find a list of the generic use cases
that need to be addressed for messages with Header Protection
(HP). These use cases apply independently of whether S/MIME, PGP/MIME
or any other technology is used to achieve HP.
(HP). These use cases apply regardless of technology (S/MIME,
PGP/MIME, etc.) used to achieve HP.
## Interactions {#interactions}
@ -300,7 +311,7 @@ specification {{RFC2045}}, ff. correctly; see
{{backward-compatibility-use-case}}.
Note: The compatibility of legacy HP systems with this new solutions,
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.
@ -336,7 +347,7 @@ c) Encryption only
# Specification {#specification}
This section contains the specification for Header Protection in
S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
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
@ -493,7 +504,7 @@ to be considered, is described in
{{I-D.autocrypt-lamps-protected-headers}}.
Unlike the option described in {{option-smime-spec}}, this option does
not use a "message/RFC822" wrapper to unambigously delimit the Inner
not use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message.
The MIME structure of an Email message looks as follows:
@ -511,9 +522,9 @@ The MIME structure of an Email message looks as follows:
{::include ../shared/fence-line.mkd}
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
The following example demonstrates how the header section and payload
of a protected body part might appear. 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.
@ -576,10 +587,10 @@ Message along with other MIME part(s).
### Inner Message Header Fields {#inner-msg-hf}
It is RECOMMEND that the Inner Messages contains all the Header Fields
of the Original Message with the exception of the following Header
Field, which MUST NOT be included to the Inner Message nor to any
other protected part of the message:
It is RECOMMENDED that the Inner Messages contains all the Header
Fields of the Original Message with the exception of the following
Header Field, which MUST NOT be included within the Inner Message nor
within any other protected part of the message:
* Bcc
@ -594,7 +605,7 @@ 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
Content-Type header field parameter "forwarded=no" as defined in
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambigously
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
the Inner Message from the rest of the message.
@ -611,11 +622,18 @@ per {{RFC8551}}.
The following Header Fields are defined as the Essential Header Fields:
* From
* To (if present in the OrigM)
* Cc (if present in the OrigM)
* Bcc (if present in the OrigM, see also {{inner-msg-hf}} and {{bcc-handling}})
* To (if present in the Original Message)
* Cc (if present in the Original Message)
* Bcc (if present in the Original Message, see also {{inner-msg-hf}}
and {{bcc-handling}})
* Date
* Message-ID
* Subject
Some of these Header Fields are required by RFC 5322 (e.g. Message-ID).
@ -623,11 +641,11 @@ Furthermore, not including certain Header
Fields may trigger spam detection to flag the message as spam and/or
lead to user experience (UX) issues.
For further Data Minimization the value of the Subject Header Field
For further Data Minimization, the value of the Subject Header Field
SHOULD be obfuscated. In addition, the value of other Essential Header
Fields MAY be obfuscated. Further Header Fields MAY be obfuscated,
though simply not adding those to the Outer Message Header SHOULD be
prefered over obfuscation. Header Field obfuscation is further
preferred over obfuscation. Header Field obfuscation is further
specified in {{obfuscation-outer-HF}}. Header Fields not obfuscated
should contain the same values as in the Original Message.
@ -686,7 +704,7 @@ the same week. \]\]
In certain implementations also the From, To, and/or Cc Header Field
MAY be obfucated. Those may be replaced by e.g.
MAY be obfuscated. Those may be replaced by e.g.
* To: Obfuscated <anonymous@anonymous.invalid>
@ -700,11 +718,15 @@ these Header Fields in clear text and is capable of processing those.
-->
A use case for obfuscation of all Outer Message Header Fields is
mixnet netwerks, 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.
adversely impacts spam filtering.
<!-- suggestion KRB:
"Further studies of the impact that Header Field obfuscation has on
spam filtering are needed."
-->
### Receiving User Facing Message Header Fields {#rufm-hf}
@ -735,7 +757,7 @@ Header Section and can never be protected.
So I think this is just a long way of saying that no extra text is needed here,
unless you want the document to explain the above.
\]\]
\]\]
-->
### Header Field Flow
@ -762,7 +784,7 @@ Legend:
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* Wrapper: MIME Header Section; with media type (message/RFC822) to
unambigously delimit the inner message from the rest of the
unambiguously delimit the inner message from the rest of the
message.
* MIME-HSp: MIME Header Section part to describe the encryption or
@ -799,7 +821,7 @@ The entity applying protection to a message must decide:
the message? This depends on user request and/or local policy as
well as availability of cryptographic keys.
* Which Header Fields of the Orignial Message shall be part of the
* Which Header Fields of the Original Message shall be part of the
Outer Message Header Section? This typically depends on local
policy. By default the Essential Header Fields are part of the Outer
Message Header Section; cf. {{outer-msg-hf}}.
@ -825,9 +847,9 @@ part, which depends on the protection level selected in
#### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
Depending on the Protection Level selected in {{sending-side-step-1}}
apply signature and/or encryption to the Original Message including
the wrapper (as per {{RFC8551}}) and set the result to the message as
Depending on the Protection Level selected in {{sending-side-step-1}},
apply signature and/or encryption to the Original Message, including
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
@ -838,12 +860,12 @@ Transport.
### Receiving Side Message Processing
When a protected message is received the following steps are applied:
When a protected message is received, the following steps are applied:
#### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
Depending on the protection level the received message is decrypted
Depending on the protection level, the received message is decrypted
and/or its signature is checked as per {{RFC8551}}.
@ -853,36 +875,36 @@ The Receiving User Facing Message is constructed according to
{{rufm-hf}}.
The resulting message is handed over for further processing, which
typically involves rendering it to the user.
typically involves rendering it for the user.
Note: It is for further study whether and, if yes, how the Outer
Message Header Section (as received from the Transport) is
preserved for the user.
Note: Further study is needed to determine whether or not the Outer
Message Header Section, as received from the Transport, is
preserved for the user, and if so, how this is to be achieved.
## Backward Compatibility Use Case {#backward-compatibility-use-case}
{{I-D.autocrypt-lamps-protected-headers}} describes a possibility to
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
achieve backward compatibility with existing S/MIME (and PGP/MIME)
implementations unaware of this specification (Legacy Display). It
implementations that predate this specification (Legacy Display). It
mainly focuses on email clients that do not render emails using header
protection (nicely) 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}} applies header protection as
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 reveal, the Legacy Display format described in
receiver be discovered, the Legacy Display format described in
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
mitigate those (backward compatibility use case).
mitigate those issues (cf. {{backward-compatibility-use-case}}).
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
has implemented this for PGP/MIME (but not yet S/MIME).
has implemented this for PGP/MIME, but not yet S/MIME.
# Security Considerations
@ -905,10 +927,11 @@ This document requests no action from IANA.
# Acknowledgments
The authors would like to thank the following people who have provided
helpful comments and suggestions for this document: 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 Acknowledgements -->
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 Acknowledgements
-->
--- back
@ -933,26 +956,25 @@ header field may appear in up to three different variants:
field, which depends on the implementation:
a) One message for each recipient in the Bcc header field
separately with a Bcc header field containing only the address
of the recipient it is sent to
separately, with a Bcc header field containing only the address
of the recipient it is sent to.
b) The same message for each recipient in the Bcc header field with
a Bcc header field containing an indication such as "Undisclosed
recipients" (but no addressees)
recipients", but no addresses.
c) The same message for each recipient in the Bcc header field
which does not include a Bcc header field (this message is
identical to 1. / cf. above)
identical to 1. / cf. above).
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
i.e., with all recipient addresses.
The most privacy preserving of the alternatives (2a, 2b, and 2c)
is to standardize 2a, as in the other
cases (2b and 2c) information about hidden recipients is revealed via
keys. In any case the message has to be cloned and adjusted depending
on the recipient.
The most privacy preserving method of the alternatives (2a, 2b, and
2c) is to standardize 2a, as in the other cases (2b and 2c),
information about hidden recipients is revealed via keys. In any case,
the message has to be cloned and adjusted depending on the recipient.
@ -976,7 +998,7 @@ on the recipient.
<!--
Alexey: it is compiant!
* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
compliant with the MIME standard, in particuar also {{RFC2046}},
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
-->

Write Preview
Loading…
Cancel
Save