edits after call Hb/HM

ietf-lamps-hp/Makefile

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

ietf-lamps-hp/draft-ietf-lamps-header-protection.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".
-
-<!-- TODO: Clean up this section with proceeding section (redundant
-     statements)
--->
+encryption" and "signature only" (cf. {{protection-levels}}):
+
+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}
-
-It is RECOMMEND that the Inner Messages contains all the original
-Header Fields with the exception of those specified in
-{{HF-exclude-inner}}.
-
+### Inner Message Header Header Fields {#inner-msg-hf}
 
-### 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 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}}.
 
-For further Data Minimization the values of some of these Header
-Fields MAY be obfuscated, which is discussed further 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
-
-Note: Should obfuscation of Subject be default?
-
-Note: It is for further study to what extent Header Field obfuscation
-(adversely) impacts Spam Filtering.
-
-\[\[ TODO: Determine whether also From, To, Cc could be obfucated, e.g.
+\[\[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the
+same week. \]\]
 
-* From: "Obfuscated" anonymous@anonymous.invalid
 
- \]\]
+In certain implementations also the From, To, and/or Cc Header Field
+MAY be obfucated. Those may be replaced by e.g.
 
-\[\[ TODO: Determine whether mixnet capabilities \{\{pep.mixnets-url\}\}
-should be described further here.
+* To: Obfuscated <anonymous@anonymous.invalid>
 
-https://dev.pep.foundation/Mixnet/Messages
-https://gitea.pep.foundation/juga/pEpPythonMixnet
-https://dev.pep.foundation/Mixnet/
-https://dev.pep.foundation/Mixnet/Mix%20networks
+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}}).
 
-### 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}}.
+Note: It is for further study to what extent Header Field obfuscation
+(adversely) impacts spam filtering.
 
-<!-- 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
+* Impact on spam filtering, if HFs are obfuscated
+  ({{obfuscation-outer-HF}})
 
-* 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}}
 
 
 <!--

shared/references/pep-mixnet.mkd

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