forked from pEp.foundation/internet-drafts
parent
d059dfd675
commit
ed5bef5050
@ -0,0 +1,42 @@
|
||||
#!/usr/bin/make -f
|
||||
|
||||
NAME := draft-ietf-lamps-header-protection-req
|
||||
REV := 00-pre20190623
|
||||
DRAFT := $(NAME)-$(REV)
|
||||
|
||||
OUTPUTS = $(DRAFT).xml $(DRAFT).txt $(DRAFT).html
|
||||
|
||||
all: $(OUTPUTS)
|
||||
|
||||
$(DRAFT).xml: $(NAME).mkd \
|
||||
../shared/author_tags/bernie_hoeneisen.mkd \
|
||||
../shared/author_tags/alexey_melnikov.mkd \
|
||||
../shared/author_tags/daniel_kahn_gillmor.mkd \
|
||||
../shared/text-blocks/key-words-rfc2119.mkd \
|
||||
../shared/text-blocks/mitm.mkd \
|
||||
#../shared/text-blocks/implementation-status.mkd \
|
||||
#../shared/author_tags/claudio_luck.mkd \
|
||||
#../shared/references/implementation-status.mkd \
|
||||
# ../shared/references/ed-keysync.mkd \
|
||||
# ../shared/references/isoc-btn.mkd \
|
||||
#../shared/text-blocks/handshake.mkd \
|
||||
# ../shared/text-blocks/trustwords.mkd \
|
||||
# ../shared/text-blocks/tofu.mkd \
|
||||
# ../shared/ascii-arts/basic-msg-flow.mkd \
|
||||
# ../shared/ascii-arts/pep_id_system.mkd \
|
||||
# to match backslash at the end of the previous line
|
||||
kramdown-rfc2629 $(NAME).mkd > $(DRAFT).xml
|
||||
|
||||
$(DRAFT).txt: $(DRAFT).xml
|
||||
xml2rfc $(DRAFT).xml
|
||||
|
||||
$(DRAFT).html: $(DRAFT).xml
|
||||
xml2rfc --html $(DRAFT).xml
|
||||
|
||||
clean:
|
||||
rm -f $(OUTPUTS)
|
||||
|
||||
distclean:
|
||||
rm -f -r $(NAME)-* .refcache
|
||||
|
||||
.PHONY: clean all
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,900 @@
|
||||
---
|
||||
coding: utf-8
|
||||
|
||||
title: "Problem Statement and Requirements for Header Protection"
|
||||
abbrev: Header Protection requirements
|
||||
docname: draft-ietf-lamps-header-protection-req-00
|
||||
category: info
|
||||
|
||||
stand_alone: yes
|
||||
pi: [toc, sortrefs, symrefs, comments]
|
||||
|
||||
author:
|
||||
{::include ../shared/author_tags/alexey_melnikov.mkd}
|
||||
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
|
||||
{::include ../shared/author_tags/daniel_kahn_gillmor.mkd}
|
||||
#{::include ../shared/author_tags/claudio_luck.mkd}
|
||||
|
||||
normative:
|
||||
# RFC822:
|
||||
# RFC1847:
|
||||
# RFC1341:
|
||||
RFC2045: # MIME part 1 #
|
||||
RFC2119:
|
||||
RFC5322: # SMTP #
|
||||
RFC8551: # S/MIME #
|
||||
|
||||
informative:
|
||||
|
||||
# RFC8301:
|
||||
# RFC8463:
|
||||
# RFC2046:
|
||||
# RFC3156:
|
||||
RFC3501: # IMAP #
|
||||
RFC4949: # Internet Security Glossary #
|
||||
# RFC4880:
|
||||
# RFC5321:
|
||||
# RFC5490:
|
||||
RFC6376: # DKIM #
|
||||
RFC6532: # internationalized email headers #
|
||||
RFC7208: # SPF #
|
||||
# RFC7258:
|
||||
# RFC7435:
|
||||
RFC7489: # DMARC #
|
||||
# RFC7942:
|
||||
I-D.melnikov-lamps-header-protection:
|
||||
I-D.birk-pep:
|
||||
I-D.marques-pep-email:
|
||||
I-D.luck-lamps-pep-header-protection:
|
||||
# I-D.marques-pep-handshake:
|
||||
# I-D.birk-pep-trustwords:
|
||||
# I-D.marques-pep-rating:
|
||||
|
||||
|
||||
--- abstract
|
||||
|
||||
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.
|
||||
|
||||
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 describes the problem statement, generic use cases, and
|
||||
requirments. Additionally it drafts possible solutions to address the
|
||||
challenge. Finally some best practices are collected.
|
||||
|
||||
|
||||
--- middle
|
||||
|
||||
|
||||
# Introduction
|
||||
|
||||
A range of protocols for the protection of electronic mail (email)
|
||||
exist, which allow to assess the authenticity and integrity of the
|
||||
email headers section or selected header fields 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.
|
||||
|
||||
<!-- HB: preserved as ommented out for the moment, as we may re-use part of this
|
||||
|
||||
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.
|
||||
{{progressive-header-disclosure}}, 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 describes the problem statement, generic use cases
|
||||
({{use-cases}}) and requirements for header protection
|
||||
({{requirements}}) 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.
|
||||
|
||||
<!-- HB: preserved as ommented out for the moment, as we may re-use part of this
|
||||
|
||||
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 ({{progressive-header-disclosure}}, ff.).
|
||||
|
||||
-->
|
||||
|
||||
\[...\]
|
||||
|
||||
# Conventions Used in This Document
|
||||
|
||||
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
|
||||
|
||||
## Terminology
|
||||
|
||||
The following terms are defined in this document:
|
||||
|
||||
* Header Field:: cf. {{RFC5322}}
|
||||
|
||||
* Header Section: cf. {{RFC5322}}
|
||||
|
||||
* Signed-only message: a multipart/signed or application/pkcs7-mime
|
||||
containing SignedData message which doesn't contain any encrypted
|
||||
layer. I.e. this is a message which is not encrypted and not
|
||||
encrypted + signed.
|
||||
|
||||
<!-- {::include ../shared/text-blocks/handshake.mkd} -->
|
||||
<!-- {::include ../shared/text-blocks/trustwords.mkd} -->
|
||||
<!-- {::include ../shared/text-blocks/tofu.mkd} -->
|
||||
{::include ../shared/text-blocks/mitm.mkd}
|
||||
|
||||
|
||||
|
||||
# Problem Statement
|
||||
|
||||
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.
|
||||
|
||||
|
||||
\[...\]
|
||||
|
||||
|
||||
# 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.
|
||||
|
||||
|
||||
## 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:
|
||||
|
||||
~~~~
|
||||
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.
|
||||
|
||||
|
||||
## Protection Levels
|
||||
|
||||
The following protection levels need to be considered:
|
||||
|
||||
a) signature and encryption
|
||||
|
||||
b) signature only
|
||||
|
||||
c) encryption only \[\[ TODO: verify whether relevant \]\]
|
||||
|
||||
|
||||
# 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.
|
||||
|
||||
## General Requirements
|
||||
|
||||
This subsection is listing the requirements to address use case 1)
|
||||
(cf. {{interactions}}).
|
||||
|
||||
~~~~
|
||||
|
||||
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.
|
||||
|
||||
|
||||
~~~~
|
||||
|
||||
### 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).
|
||||
|
||||
~~~~
|
||||
|
||||
### 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.
|
||||
|
||||
~~~~
|
||||
|
||||
## Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection
|
||||
|
||||
This sub-section addresses the use cases 2) - 4) (cf. {{interactions}})
|
||||
|
||||
~~~~
|
||||
|
||||
B1: Depending on the solution, define a means to distinguish between
|
||||
forwarded messages and encapsulated messages using new HP
|
||||
mechanism.
|
||||
|
||||
~~~~
|
||||
|
||||
### 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.
|
||||
|
||||
~~~~
|
||||
|
||||
### Receiving side
|
||||
|
||||
~~~~
|
||||
|
||||
BR1: Define how full HP support can be detected in incoming messages.
|
||||
|
||||
~~~~
|
||||
|
||||
## Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)
|
||||
|
||||
This sub-section addresses the use cases 5) - 9) (cf. {{interactions}}).
|
||||
|
||||
~~~~
|
||||
|
||||
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.
|
||||
|
||||
~~~~
|
||||
|
||||
### 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.
|
||||
|
||||
~~~~
|
||||
|
||||
### Receiving Side
|
||||
|
||||
~~~~
|
||||
|
||||
LSR1: Determine how legacy HP support can be detected in incoming
|
||||
messages.
|
||||
|
||||
~~~~
|
||||
|
||||
|
||||
<!-- =========================================================================== -->
|
||||
|
||||
|
||||
|
||||
# Options to Achieve 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.
|
||||
|
||||
## Option 1: Memory Hole {#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]\]
|
||||
|
||||
|
||||
## Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping}
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### Content-Type property "forwarded"
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
### Handling of S/MIME protected header
|
||||
|
||||
\[\[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:
|
||||
|
||||
|
||||
|
||||
1. If a header field is being encrypted because it is sensitive, its
|
||||
true value MUST NOT be included in the outer header. If the
|
||||
header field is mandatory according to {{RFC5322}}, a stub value (or
|
||||
a value indicating that the outer value is not to be used) is to
|
||||
be included in the outer header section.
|
||||
|
||||
2. The outer header section SHOULD be minimal in order to avoid
|
||||
disclosure of confidential information. It is recommended that
|
||||
the outer header section only contains "Date" (set to the same
|
||||
value as in the inner header field, or, if the Date value is also
|
||||
sensitive, to Monday 9am of the same week), possibly "Subject"
|
||||
and "To"/"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.
|
||||
|
||||
3. The "Subject" header field value of the outer header section
|
||||
SHOULD either be identical to the inner "Subject" header field
|
||||
value, or contain a clear indication that the outer value is not
|
||||
to be used for display (the inner header field value would
|
||||
contain the true value).
|
||||
|
||||
Note that recommendations listed above typically only apply to non
|
||||
MIME header fields (header fields with names not starting with
|
||||
"Content-" prefix), but there are 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):
|
||||
|
||||
1. 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.
|
||||
|
||||
### Mail User Agent Algorithm for deciding which version of a header
|
||||
field to display
|
||||
|
||||
\[\[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.\]\]
|
||||
|
||||
|
||||
|
||||
## Option 3: Progressive Header Disclosure {#progressive-header-disclosure}
|
||||
|
||||
This option is similar to Option 2 (cf. {{rfc822-wrapping}}). It also
|
||||
makes use the Content-Type property "forwarded"
|
||||
(cf. {{content-type-property-forwarded}}).
|
||||
|
||||
## Design principles
|
||||
|
||||
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 {{content-type-property-forwarded}})
|
||||
described Content-Type property "forwarded" to distinguish between
|
||||
encapsulated and forwarded emails.
|
||||
|
||||
## Candidate Header Fields for Header Protection
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
## 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:
|
||||
|
||||
* Date
|
||||
* From
|
||||
* To
|
||||
* Cc (*)
|
||||
* Bcc (*)
|
||||
|
||||
The entries with an asterisk mark (*) should only be set if also present in the
|
||||
original message.
|
||||
|
||||
|
||||
## More information
|
||||
|
||||
More information on progressive header disclosure can be found in
|
||||
{{I-D.marques-pep-email}} and
|
||||
{{I-D.luck-lamps-pep-header-protection}}. The latter is a predecessor
|
||||
of this document.
|
||||
|
||||
|
||||
|
||||
|
||||
# Examples
|
||||
|
||||
|
||||
Examples in subsequent sections assume that an email client is trying
|
||||
to protect (sign) the following initial message:
|
||||
|
||||
~~~~
|
||||
|
||||
Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
MIME-Version: 1.0
|
||||
MMHS-Primary-Precedence: 3
|
||||
Subject: Meeting at my place
|
||||
To: somebody@example.net
|
||||
X-Mailer: Isode Harrier Web Server
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
Without message header protection the corresponding signed message
|
||||
might look like this. (Lines prepended by "O: " are the outer
|
||||
header.)
|
||||
|
||||
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
O: Subject: Meeting at my place
|
||||
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
O: MIME-Version: 1.0
|
||||
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1;
|
||||
O: protocol="application/pkcs7-signature";
|
||||
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
|
||||
This is a multipart message in MIME format.
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Transfer-Encoding: base64
|
||||
content-type: application/pkcs7-signature
|
||||
|
||||
[[base-64 encoded signature]]
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
|
||||
|
||||
|
||||
~~~~
|
||||
|
||||
## Option 1: Memory Hole {#memory-hole-example}
|
||||
|
||||
|
||||
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.
|
||||
|
||||
~~~~
|
||||
|
||||
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
O: Subject: Meeting at my place
|
||||
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
O: MIME-Version: 1.0
|
||||
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1;
|
||||
O: protocol="application/pkcs7-signature";
|
||||
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
|
||||
This is a multipart message in MIME format.
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
I: MIME-Version: 1.0
|
||||
I: MMHS-Primary-Precedence: 3
|
||||
I: Subject: Meeting at my place
|
||||
I: To: somebody@example.net
|
||||
I: X-Mailer: Isode Harrier Web Server
|
||||
I: Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Transfer-Encoding: base64
|
||||
content-type: application/pkcs7-signature
|
||||
|
||||
[[base-64 encoded signature]]
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
|
||||
|
||||
~~~~
|
||||
|
||||
## Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping-example}
|
||||
|
||||
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.
|
||||
|
||||
|
||||
~~~~
|
||||
|
||||
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
O: Subject: Meeting at my place
|
||||
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
O: MIME-Version: 1.0
|
||||
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1;
|
||||
O: protocol="application/pkcs7-signature";
|
||||
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
|
||||
This is a multipart message in MIME format.
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
W: Content-Type: message/rfc822; forwarded=no
|
||||
W:
|
||||
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@mattingly.example.net>
|
||||
I: MIME-Version: 1.0
|
||||
I: MMHS-Primary-Precedence: 3
|
||||
I: Subject: Meeting at my place
|
||||
I: To: somebody@example.net
|
||||
I: X-Mailer: Isode Harrier Web Server
|
||||
I: Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Transfer-Encoding: base64
|
||||
content-type: application/pkcs7-signature
|
||||
|
||||
[[base-64 encoded signature]]
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
|
||||
|
||||
~~~~
|
||||
|
||||
## Option 3 Progressive Header Disclosure {#progressive-header-disclosure-example}
|
||||
|
||||
This looks similar as in option 2. Specific examples can be found in
|
||||
{{I-D.luck-lamps-pep-header-protection}}.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- =========================================================================== -->
|
||||
|
||||
|
||||
# Security Considerations
|
||||
|
||||
This document talks about UI considerations, including security
|
||||
considerations, when processing messages protecting header fields.
|
||||
One of the goals of this document is to specify UI for displaying
|
||||
such messages which is less confusing/misleading 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.
|
||||
|
||||
|
||||
|
||||
# Privacy Considerations
|
||||
|
||||
\[\[ TODO \]\]
|
||||
|
||||
|
||||
# IANA Considerations
|
||||
|
||||
This document requests no action from IANA.
|
||||
|
||||
\[\[ RFC Editor: This section may be removed before publication. \]\]
|
||||
|
||||
|
||||
# Acknowledgements
|
||||
|
||||
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.
|
||||
|
||||
|
||||
--- back
|
||||
|
||||
# Document Changelog
|
||||
|
||||
\[\[ RFC Editor: This section is to be removed before publication \]\]
|
||||
|
||||
* draft-ietf-lamps-header-protection-req-00
|
||||
* Initial version
|
||||
|
||||
# Open Issues
|
||||
|
||||
\[\[ RFC Editor: This section should be empty and is to be removed
|
||||
before publication. \]\]
|
||||
|
||||
* filename of the document
|
||||
* does draft-ietf-lamps-header-protection-req work to keep
|
||||
draft-ietf-lamps-header-protection free for the specification? Or
|
||||
do we expect only one document at the end of the day?
|
||||
|
||||
* 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.
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
LocalWords: utf docname toc sortrefs symrefs Oberer Graben uri Ucom
|
||||
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
|
||||
LocalWords: UX Programme Changelog
|
||||
-->
|
||||
@ -0,0 +1,13 @@
|
||||
|
||||
-
|
||||
ins: A. Melnikov
|
||||
name: Alexey Melnikov
|
||||
org: Isode Ltd
|
||||
street: 14 Castle Mews
|
||||
city: Hampton, Middlesex
|
||||
code: TW12 2NP
|
||||
country: UK
|
||||
email: alexey.melnikov@isode.com
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,10 @@
|
||||
|
||||
-
|
||||
ins: D. Gillmor
|
||||
name: Daniel Kahn Gillmor
|
||||
org: American Civil Liberties Union
|
||||
street: 125 Broad St.
|
||||
city: New York, NY
|
||||
code: 10004
|
||||
country: USA
|
||||
email: dkg@fifthhorseman.net
|
||||
Loading…
Reference in new issue