forked from pEp.foundation/internet-drafts
edits after call Hb/HM
parent
5851409ab6
commit
423348d94b
|
|
@ -13,6 +13,7 @@ all: $(OUTPUTS)
|
|||
$(DRAFT).xml: $(NAME).mkd \
|
||||
../shared/author_tags/bernie_hoeneisen.mkd \
|
||||
../shared/author_tags/alexey_melnikov.mkd \
|
||||
../shared/references/pep-mixnet.mkd \
|
||||
../shared/text-blocks/key-words-rfc2119.mkd \
|
||||
../shared/text-blocks/terms-intro.mkd \
|
||||
../shared/text-blocks/mitm.mkd \
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ pi: [toc, sortrefs, symrefs, comments]
|
|||
|
||||
author:
|
||||
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
|
||||
#{::include ../shared/author_tags/alexey_melnikov.mkd}
|
||||
{::include ../shared/author_tags/alexey_melnikov.mkd}
|
||||
#{::include ../shared/author_tags/daniel_kahn_gillmor.mkd}
|
||||
|
||||
normative:
|
||||
|
|
@ -49,6 +49,7 @@ informative:
|
|||
# I-D.marques-pep-handshake:
|
||||
# I-D.birk-pep-trustwords:
|
||||
# I-D.marques-pep-rating:
|
||||
{::include ../shared/references/pep-mixnet.mkd}
|
||||
|
||||
|
||||
--- abstract
|
||||
|
|
@ -179,26 +180,26 @@ determined by the IETF LAMPS WG.
|
|||
* Encryption only (protection level): If encryption (but no
|
||||
cryptographic signing) is applied to a message.
|
||||
|
||||
* Original Message: The message to be protected before any protection
|
||||
related processing has been applied on the sender side.
|
||||
* Original Message (OrigM): The message to be protected before any
|
||||
protection related processing has been applied on the sending side.
|
||||
|
||||
* Inner Message: The message to be protected, shortly before
|
||||
protection measures are applied to on the sender side or the message
|
||||
shortly after unwrapping on the receiver side. Typically the Inner
|
||||
* Inner Message (InM): The message to be protected, shortly before
|
||||
protection measures are applied to on the sending side or the message
|
||||
shortly after unwrapping on the receiving side. Typically the Inner
|
||||
Message is in clear text and often the Inner Message is the same or
|
||||
similar as the Original Message. The Inner Message MUST be the same
|
||||
on the sender and the receiver side.
|
||||
on the sending and the receiving side.
|
||||
|
||||
* Outer Message: The Message as handed over to the Transport or
|
||||
* Outer Message (OutM): The Message as handed over to the Transport or
|
||||
received from the Transport respectively. The Outer Message
|
||||
typically differs on the sender and the receiver side.
|
||||
typically differs on the sending and the receiving side.
|
||||
|
||||
* User Facing Message: The message used for rendering after the Outer
|
||||
Message Header Section has been merged with the Inner Message Header
|
||||
Section.
|
||||
* Receiving User Facing Message (RUFM): The message used for rendering
|
||||
at the receiving side after the Outer Message Header Section has
|
||||
been merged with the Inner Message Header Section.
|
||||
|
||||
* Essential Header Fields: The Header Fields an Outer Message Header
|
||||
Section SHOULD contain at least; cf. {{HF-include-outer}}.
|
||||
* Essential Header Fields (EHF): The Header Fields an Outer Message
|
||||
Header Section SHOULD contain at least; cf. {{outer-msg-hf}}.
|
||||
|
||||
* Protected: Protected refers to the parts of a message where
|
||||
protection measures of any Protection Levels have been applied to.
|
||||
|
|
@ -335,9 +336,6 @@ a) Signature and encryption
|
|||
Messages containing a cryptographic signature which
|
||||
are also encrypted.
|
||||
|
||||
Sending and receiving side SHOULD implement 'signature and
|
||||
encryption', which is the default to use on the sending side.
|
||||
|
||||
|
||||
b) Signature only
|
||||
|
||||
|
|
@ -350,20 +348,12 @@ b) Signature only
|
|||
encrypted layer.
|
||||
-->
|
||||
|
||||
Certain implementations MAY decide to send 'signature only'
|
||||
messages, depending on the circumstances and customer requirements.
|
||||
Sending and Receiving sides SHOULD implement 'signature only'.
|
||||
|
||||
|
||||
c) Encryption only
|
||||
|
||||
Messages that encryption is applied to which do not contain a
|
||||
cryptographic signature.
|
||||
|
||||
'Encryption only' is NOT RECOMMENDED on the sending side, however
|
||||
the receiving side needs certain guidelines on how to process
|
||||
received 'encrypted only' messages
|
||||
|
||||
|
||||
# Specification {#specification}
|
||||
|
||||
|
|
@ -376,16 +366,21 @@ Furthermore, it is likely that PGP/MIME {{RFC3156}} will also take
|
|||
over this specification or parts of it.
|
||||
|
||||
This specification applies to the protection levels "signature &
|
||||
encryption" and "signature only". It generally is NOT RECOMMENDED to send
|
||||
a message with protection level "encryption only". On the other hand,
|
||||
messages with protection level "encryption only" might arrive at the
|
||||
receiving side. While not targeted to protection level "encryption
|
||||
only", this specification is assumed to also function for "encryption
|
||||
only".
|
||||
encryption" and "signature only" (cf. {{protection-levels}}):
|
||||
|
||||
<!-- TODO: Clean up this section with proceeding section (redundant
|
||||
statements)
|
||||
-->
|
||||
Sending and receiving sides SHOULD implement "signature and
|
||||
encryption", which is the default to use on the sending side.
|
||||
|
||||
Certain implementations MAY decide to send "signature only" messages,
|
||||
depending on the circumstances and customer requirements. Sending
|
||||
side MAY and receiving sides SHOULD implement "signature only".
|
||||
|
||||
It generally is NOT RECOMMENDED to send a message with protection
|
||||
level "encryption only". On the other hand, messages with protection
|
||||
level "encryption only" might arrive at the receiving side. While not
|
||||
targeted to protection level "encryption only", this specification is
|
||||
assumed to also function for "encryption only". Receiving sides SHOULD
|
||||
implement "encryption only".
|
||||
|
||||
Note: It is for further study whether or not more guidance for
|
||||
handling messages with protection level "encryption only" at the
|
||||
|
|
@ -483,10 +478,10 @@ The Outer Message Header Section is unprotected, while the remainder
|
|||
the MIME header Section and the Inner Message (Header Section and
|
||||
Body). The Inner Message Header Section is the same as (or a subset
|
||||
of) the Original Message Header Section
|
||||
(cf. {{HF-include-inner}}). The Inner Message Body is the same as the
|
||||
(cf. {{inner-msg-hf}}). The Inner Message Body is the same as the
|
||||
Original Message Body (before header protection has been applied).
|
||||
|
||||
The original message itself may contain any defined MIME structure.
|
||||
The Original Message itself may contain any defined MIME structure.
|
||||
|
||||
There may also be an additional MIME layer with Media-Type
|
||||
"multipart/mixed" in the Outer Message Body to contain the Inner
|
||||
|
|
@ -532,17 +527,12 @@ For further information, the reader is encouraged to consult
|
|||
{{I-D.autocrypt-lamps-protected-headers}}.
|
||||
|
||||
|
||||
### Header Fields to Include to the Inner Message Header Section {#HF-include-inner}
|
||||
### Inner Message Header Header Fields {#inner-msg-hf}
|
||||
|
||||
It is RECOMMEND that the Inner Messages contains all the original
|
||||
Header Fields with the exception of those specified in
|
||||
{{HF-exclude-inner}}.
|
||||
|
||||
|
||||
### Header Fields to Exclude from the Inner Message Header Section {#HF-exclude-inner}
|
||||
|
||||
The following Header Field MUST NOT be included to the Inner Message
|
||||
nor to any other protected part of the message:
|
||||
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:
|
||||
|
||||
* Bcc
|
||||
|
||||
|
|
@ -551,38 +541,43 @@ nor to any other protected part of the message:
|
|||
with Bcc recipients. \]\]
|
||||
|
||||
|
||||
### Header Fields to Include to the Outer Message Header Section {#HF-include-outer}
|
||||
### Outer Message Header Fields {#outer-msg-hf}
|
||||
|
||||
The Outer Message Header Section is a subset of the Inner Message
|
||||
Header Section plus the Header Fields specified in
|
||||
{{HF-exclude-inner}} plus the MIME Header Section part to describe the
|
||||
The Outer Message Header Section is a subset of the Original Message (OrigM)
|
||||
Header Section plus the MIME Header Section part to describe the
|
||||
encryption or signature.
|
||||
|
||||
To maximize Privacy, it is strongly RECOMMENDED to follow the
|
||||
principle of Data Minimization (cf. {{privacy}}).
|
||||
|
||||
However, the Outer Message Header Section SHOULD contain at least the
|
||||
Essential Header Fields and MUST also contain the Header Fields of the
|
||||
MIME Header Section part.
|
||||
However, the Outer Message Header Section SHOULD contain the Essential
|
||||
Header Fields and MUST also contain the Header Fields of the MIME
|
||||
Header Section part.
|
||||
|
||||
The following Header Fields are defined as the Essential Header Fields:
|
||||
|
||||
* From
|
||||
* To
|
||||
* Cc (if present)
|
||||
* Bcc (if present, see also {{HF-include-outer}} and {{bcc-handling}})
|
||||
* To (if present in the OrigM)
|
||||
* Cc (if present in the OrigM)
|
||||
* Bcc (if present in the OrigM, see also {{outer-msg-hf}} and {{bcc-handling}})
|
||||
* Date
|
||||
* Message-ID
|
||||
* Subject
|
||||
|
||||
Most of these Header Fields are needed by the Transport (e.g. to
|
||||
Some of these Header Fields are needed by the Transport (e.g. to
|
||||
determine the destination). Furthermore, not including certain Header
|
||||
Fields may trigger Spam Detection to flag the message as Spam and/or
|
||||
lead to User Experience (UX) issues.
|
||||
Fields may trigger spam detection to flag the message as spam and/or
|
||||
lead to user experience (UX) issues.
|
||||
|
||||
For further Data Minimization the values of some of these Header
|
||||
Fields MAY be obfuscated, which is discussed further in
|
||||
{{obfuscation-outer-HF}}.
|
||||
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
|
||||
specified in {{obfuscation-outer-HF}}.
|
||||
|
||||
Header Fields not obfuscated SHOULD contain the same values as in the
|
||||
Original Message.
|
||||
|
||||
The MIME Header Section part is the collection of MIME Header Fields
|
||||
describing the following MIME structure as defined in {{RFC2045}}.
|
||||
|
|
@ -608,58 +603,45 @@ message (using application/pkcs7-mime with SignedData):
|
|||
{::include ../shared/fence-line.mkd}
|
||||
|
||||
Depending on the scenario, further Header Fields MAY be exposed in the
|
||||
Outer Message Header Section, however - as stated above - this is NOT
|
||||
RECOMMENDED unless justified. Such Header Fields may include e.g.:
|
||||
Outer Message Header Section, which is NOT RECOMMENDED unless
|
||||
justified. Such Header Fields may include e.g.:
|
||||
|
||||
* References
|
||||
* Reply-To
|
||||
* In-Reply-To
|
||||
|
||||
|
||||
#### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
|
||||
|
||||
If certain values of the following Outer Message Header Fields are
|
||||
If the values of the following Outer Message Header Fields are
|
||||
obfuscated, those SHOULD assume the following values:
|
||||
|
||||
~~~
|
||||
|
||||
* Subject: ...
|
||||
* Message-ID: <new randomly generated ID>
|
||||
* Message-ID: <new randomly generated Message-ID>
|
||||
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
|
||||
|
||||
~~~
|
||||
|
||||
Note: Alternative for Date: set to Monday 9am of the same week
|
||||
\[\[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the
|
||||
same week. \]\]
|
||||
|
||||
Note: Should obfuscation of Subject be default?
|
||||
|
||||
In certain implementations also the From, To, and/or Cc Header Field
|
||||
MAY be obfucated. Those may be replaced by e.g.
|
||||
|
||||
* To: Obfuscated <anonymous@anonymous.invalid>
|
||||
|
||||
Such implementations need to ensure that the Transport has access
|
||||
to these Header Fields in clear text and is capable to process 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}}).
|
||||
|
||||
Note: It is for further study to what extent Header Field obfuscation
|
||||
(adversely) impacts Spam Filtering.
|
||||
(adversely) impacts spam filtering.
|
||||
|
||||
\[\[ TODO: Determine whether also From, To, Cc could be obfucated, e.g.
|
||||
|
||||
* From: "Obfuscated" anonymous@anonymous.invalid
|
||||
|
||||
\]\]
|
||||
|
||||
\[\[ TODO: Determine whether mixnet capabilities \{\{pep.mixnets-url\}\}
|
||||
should be described further here.
|
||||
|
||||
https://dev.pep.foundation/Mixnet/Messages
|
||||
https://gitea.pep.foundation/juga/pEpPythonMixnet
|
||||
https://dev.pep.foundation/Mixnet/
|
||||
https://dev.pep.foundation/Mixnet/Mix%20networks
|
||||
|
||||
\]\]
|
||||
|
||||
### Header Fields to Exclude from the Outer Message Header Section {#HF-exclude-outer}
|
||||
|
||||
The Outer Message Header Section SHOULD NOT contain any non-essential
|
||||
Header Fields. The essential Header Fields are defined in
|
||||
{{HF-include-outer}}.
|
||||
|
||||
<!-- TODO: combine this and last section; same for Inner -->
|
||||
|
||||
### Message Processing
|
||||
### Message Processing {#message-processing}
|
||||
|
||||
#### Sending Side
|
||||
|
||||
|
|
@ -667,7 +649,7 @@ For a protected message the following steps are applied before a
|
|||
message can be handed over to the Transport:
|
||||
|
||||
|
||||
##### Step 1: Decide on Protection Level and Information Disclosure {#sender-side-step-1}
|
||||
##### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
|
||||
|
||||
The entity applying protection to a message must decide:
|
||||
|
||||
|
|
@ -675,33 +657,34 @@ 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 shall be part of the Outer Message Header
|
||||
Section? This typically depends on local policy. By default the
|
||||
Header Fields listed in {{HF-include-outer}} are part of the Outer
|
||||
Message Header Section.
|
||||
* Which Header Fields of the Orignial 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 (in addition to the MIME Header Section
|
||||
part); cf. {{outer-msg-hf}}.
|
||||
|
||||
* Which of these Header Fields are to be obfuscated? This depends on
|
||||
local policy and/or specific Privacy requirements of the user. By
|
||||
default only the Subject Header Field is
|
||||
obfuscated. (cf. {{obfuscation-outer-HF}})
|
||||
obfuscated; cf. {{obfuscation-outer-HF}}.
|
||||
|
||||
|
||||
##### Step 2: Compose the Outer Message Header Section {#sender-side-step-2}
|
||||
##### Step 2: Compose the Outer Message Header Section {#sending-side-step-2}
|
||||
|
||||
Depending on the decision in {{sender-side-step-1}}, compose the Outer
|
||||
Depending on the decision in {{sending-side-step-1}}, compose the Outer
|
||||
Message Header Section. (Note that this also includes the necessary
|
||||
MIME Header Section part for the following protection layer.)
|
||||
|
||||
Outer Header Fields that are not obfuscated SHOULD contain the same
|
||||
values as in the Original Message (except for MIME Header Section
|
||||
part, which depends on the protection level selected in
|
||||
{{sender-side-step-1}}).
|
||||
{{sending-side-step-1}}).
|
||||
|
||||
|
||||
##### Step 3: Apply Protection to the Original Message {#sender-side-step-3}
|
||||
##### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
|
||||
|
||||
Depending on the protection level in selected in
|
||||
{{sender-side-step-1}} apply signature and/or encryption to the
|
||||
{{sending-side-step-1}} apply signature and/or encryption to the
|
||||
original message (as per {{RFC8551}}) and include the result to the
|
||||
message as Outer Message Body.
|
||||
|
||||
|
|
@ -716,28 +699,30 @@ Transport.
|
|||
When a protected message is received the following steps are applied:
|
||||
|
||||
|
||||
##### Step 1: Decrypt message and/or check signature {#received-side-step-1}
|
||||
##### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
|
||||
|
||||
Depending on the protection level the received message is decrypted
|
||||
and/or its signature is checked as per {{RFC8551}}.
|
||||
|
||||
|
||||
##### Step 2: Construct the Receiving User Facing Message {#received-side-step-2}
|
||||
##### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2}
|
||||
|
||||
The Receiving User Facing Message is constructed as follows:
|
||||
|
||||
The receiving User Facing Message is constructed as follows:
|
||||
|
||||
* The Header Section of the User Facing Message MUST consist of the
|
||||
Outer Message Header Fields that are not contained in the Inner
|
||||
Message Header Section, and the Inner Message Header Fields
|
||||
* The Header Section of the Receiving User Facing Message MUST consist
|
||||
of the Outer Message Header Fields that are not contained in the
|
||||
Inner Message Header Section, and the Inner Message Header Fields
|
||||
(i.e. the Inner Message Header Field MUST always take precedence).
|
||||
|
||||
* The Body of the User Facing Message Body MUST be the same as the
|
||||
Inner Message Body.
|
||||
* The Body of the Receiving User Facing Message Body MUST be the same
|
||||
as the Inner Message Body.
|
||||
|
||||
The resulting message is handed over for further processing, which
|
||||
typically involves rendering it to the user.
|
||||
|
||||
\[\[ TODO: Do we need to take special care for HFs, which may appear
|
||||
multiple times, e.g. Received HF? \]\]
|
||||
|
||||
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.
|
||||
|
|
@ -791,7 +776,7 @@ 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: depending on authors, add Alexey / DKG -->
|
||||
<!-- TODO: add DKG either to authors or to Acknowledgements -->
|
||||
|
||||
--- back
|
||||
|
||||
|
|
@ -851,21 +836,23 @@ header field may appear in up to three different variants:
|
|||
before publication. \]\]
|
||||
|
||||
* Decide on format of obfuscated HFs, in particular Date HF
|
||||
({{obfuscation-outer-HF}})
|
||||
|
||||
* Do we need to mention something about the envelope (some HF may no
|
||||
longer be readable, but need for envelope) ?
|
||||
* Impact on spam filtering, if HFs are obfuscated
|
||||
({{obfuscation-outer-HF}})
|
||||
|
||||
* Impact on Spam Filtering, if HFs are obfuscated
|
||||
|
||||
* More examples
|
||||
* More examples (e.g. in {{message-processing}})
|
||||
|
||||
* Should Outer Message Header Section (as received) be preserved for
|
||||
the user?
|
||||
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 {{mime-format}}?
|
||||
SHOULD to MUST ({{mime-format}})?
|
||||
|
||||
* Decide on whether or not merge requirement from
|
||||
* Decide on whether or not merge requirements from
|
||||
{{I-D.ietf-lamps-header-protection-requirements}} into this
|
||||
document.
|
||||
|
||||
|
|
@ -874,13 +861,14 @@ header field may appear in up to three different variants:
|
|||
|
||||
* Enhance Introduction and Problem Statement sections
|
||||
|
||||
* Decide in whether or not more legacy HP requirements should be
|
||||
in this document
|
||||
* Decide on whether or not specification for more legacy HP
|
||||
requirements should be added to this document
|
||||
|
||||
* Improve definitions in {{protection-levels}}
|
||||
|
||||
* Privacy Considerations
|
||||
* Privacy Considerations {{privacy-considerations}}
|
||||
|
||||
* Security Considerations {{security-considerations}}
|
||||
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
pEp.mixnet:
|
||||
target: https://dev.pep.foundation/Mixnet
|
||||
title: "Mixnet"
|
||||
author:
|
||||
#name: Juga
|
||||
#ins: Juga
|
||||
org: pEp Foundation
|
||||
date: 2020-06
|
||||
Loading…
Reference in New Issue