results of phonecall HM/HB

ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd

@@ -135,8 +135,11 @@ determined by the IETF LAMPS WG.
   optionally, by a Body; cf. {{RFC5322}}.
 
 * Transport: The entity taking care of the transport of a Message
-  towards the receiver or from the sender. The Transport is
-  typically implemented in MTA (Mail Transfer Agent).
+  towards the receiver or from the sender. The Transport on the
+  sending side typically determines the destination recipients by
+  reading the To, Cc and Bcc Header Header Fields (of the Outer
+  Message). The Transport is typically implemented by an MTA (Mail
+  Transfer Agent).
 
 * Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning
   with a field name, followed by a colon (":"), followed by a field
@@ -230,7 +233,7 @@ In the following a set of challenges to be addressed:
 
 \[\[ TODO: enhance this section, add more items to the following \]\]
 
-## Privacy
+## Privacy {#privacy}
 
 * Data Minimization, which includes data spareness and hiding all
   technically concealable information whenever possible
@@ -365,7 +368,7 @@ c) Encryption only
 # Specification {#specification}
 
 This section contains the specification for Header Protection in
-S/MIME to update and clarify Section 3.1 of {{RFC8551}} (S/MIME
+S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
 4.0). This specification is likely to be integrated into S/MIME at
 some later stage.
 
@@ -375,11 +378,15 @@ 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" may arrive at the
+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)
+-->
+
 Note: It is for further study whether or not more guidance for
 handling messages with protection level "encryption only" at the
 receiving side is needed.
@@ -492,9 +499,10 @@ An alternative Option (based on the former autocrypt "Memory Hole" approach)
 to be considered, is described in
 {{I-D.autocrypt-lamps-protected-headers}}.
 
-That option emphasizes backward compatibility challenges to existing Mail
-User Agents (MUAs) that do encryption, but are unaware of Header
-Protection (see also {{backward-compatibility-use-case}}).
+That option emphasizes backward compatibility challenges to existing
+Mail User Agents (MUAs) that do encryption, but are unaware of Header
+Protection as specified herein (see also
+{{backward-compatibility-use-case}}).
 
 That option suggests to use the media type "text/plain" to contain the
 Inner Message (as opposed to "message/RFC822",
@@ -538,6 +546,10 @@ nor to any other protected part of the message:
 
 * Bcc
 
+\[\[ TODO: Bcc handling needs to be further specified (see also
+     {{bcc-handling}}). Certain MUAs cannot properly decrypt messages
+     with Bcc recipients. \]\]
+
 
 ### Header Fields to Include to the Outer Message Header Section {#HF-include-outer}
 
@@ -547,27 +559,30 @@ Header Section plus the Header Fields specified in
 encryption or signature.
 
 To maximize Privacy, it is strongly RECOMMENDED to follow the
-principle of Data Minimization, which includes data spareness and
-hiding all technically concealable information whenever possible.
+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.
 
-The Essential Header Fields are defined as the following Header
-Fields:
+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}})
 * Date
 * Message-ID
 * Subject
 
-Not including those may trigger Spam Detection to flag the message as
-Spam and/or lead to User Experience (UX) issues.
+Most 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.
 
-For further Data Minimization the values of these Header Fields MAY be
-obfuscated, which is discussed further 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}}.
 
 The MIME Header Section part is the collection of MIME Header Fields
 describing the following MIME structure as defined in {{RFC2045}}.
@@ -594,17 +609,12 @@ message (using application/pkcs7-mime with SignedData):
 
 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
+RECOMMENDED unless justified. Such Header Fields may include e.g.:
 
-* Cc
-* Bcc
 * References
 * Reply-To
 * In-Reply-To
 
-\[\[ Open Issue: Should Cc HF be included anyways, if present and if To HF
-is not obfuscated? \]\]
-
 #### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
 
 If certain values of the following Outer Message Header Fields are
@@ -612,34 +622,42 @@ obfuscated, those SHOULD assume the following values:
 
 ~~~
 
-* From: "Obfuscated" anonymous@anonymous.invalid
-* To: "Obfuscated" anonymous@anonymous.invalid
-* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
 * Subject: ...
-* Message-ID: <randomly generated ID> 
+* Message-ID: <new randomly generated 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?
-
-In any case, it MUST be ensured that the Transport has access to the
-envelope information containing the source and destination(s) of a
-message.
-
-\[\[ TODO: Do we need this explanation about the envelope? \]\]
+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.
+
+* 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}.
+{{HF-include-outer}}.
 
+<!-- TODO: combine this and last section; same for Inner -->
 
 ### Message Processing 
 
@@ -658,23 +676,26 @@ The entity applying protection to a message must decide:
   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
+  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 of these Header Fields are to be obfuscated?  This depends on
   local policy and/or specific Privacy requirements of the user. By
-  Default no Header Field is obfuscated. (cf. {{obfuscation-outer-HF}})
+  default only the Subject Header Field is
+  obfuscated. (cf. {{obfuscation-outer-HF}})
 
 
 ##### Step 2: Compose the Outer Message Header Section {#sender-side-step-2}
 
 Depending on the decision in {{sender-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}}).
+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}}).
 
 
 ##### Step 3: Apply Protection to the Original Message {#sender-side-step-3}
@@ -737,28 +758,19 @@ this time, none of the samples in
 specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
 Type "message/RFC822".)
 
-Should serious Backward Compatibly issues with rendering at the
-receiver show up, {{I-D.autocrypt-lamps-protected-headers}} may serve
-as a basis to mitigate those.
+Should serious backward compatibility issues with rendering at the
+receiver show up, the Legacy Display format described in
+{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
+mitigate those.
 
 Another variant of backward compatibility has been implemented by pEp
-{{I-D.pep-email}}, i.e. pEp Message Format 1.0. At this time pEp
+{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
 has only been implementing PGP/MIME, but not yet S/MIME.
 
 
 # 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 for the end-user and thus
-more secure.
-
-This document does not define new protocols, and thus does not create
-new security concerns in and of itself. Existing security concerns
-addressed in S/MIME {{RFC8551}}, MIME {{RFC2045}}, and Email
-{{RFC5322}} still apply to header fields and should be taken into
-consideration.
+\[\[ TODO \]\]
 
 
 # Privacy Considerations
@@ -791,7 +803,7 @@ Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.
 # Additional information
 
 
-## Stored Variants of Messages with Bcc
+## Stored Variants of Messages with Bcc {#bcc-handling}
 
 Messages containing at least one recipient address in the Bcc
 header field may appear in up to three different variants:
@@ -838,8 +850,6 @@ header field may appear in up to three different variants:
 \[\[ RFC Editor: This section should be empty and is to be removed
      before publication. \]\]
 
-* Include CC by default/always to Outer HS?
-
 * Decide on format of obfuscated HFs, in particular Date HF
 
 * Do we need to mention something about the envelope (some HF may no