edits after call Hb/HM

master
Bernie Hoeneisen 2020-06-25 22:56:08 +02:00
parent 5851409ab6
commit 423348d94b
3 changed files with 124 additions and 127 deletions

View File

@ -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 \

View File

@ -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}}
<!--

View File

@ -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