Implemented Feedback from Kelly and Berna; tnx!

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

@@ -69,7 +69,7 @@ the S/MIME specification for header protection.
 # Introduction
 
 A range of protocols for the protection of electronic mail (email)
-exist, which allow to assess the authenticity and integrity of the
+exists, which allows to assess the authenticity and integrity of the
 email headers section or selected header fields (HF) from the
 domain-level perspective, specifically DomainKeys Identified Mail
 (DKIM) {{RFC6376}} and Sender Policy Framework (SPF) {{RFC7208}}, and
@@ -79,7 +79,7 @@ a range of attacks on email, do not offer (full) end-to-end protection
 to the header section and are not capable of providing privacy for the
 information contained therein.
 
-The need for means of Data Minimization, which includes data spareness
+The need for means of Data Minimization, which includes data sparseness
 and hiding all technically concealable information whenever possible,
 has grown in importance over the past several years.
 
@@ -99,9 +99,13 @@ Several varying implementations of end-to-end protections for email
 header sections exist, though the total number of such implementations
 appears to be rather low.
 
-Some LAMPS WG participants expressed the opinion that whatever
-mechanism will be chosen, it should not be limited to S/MIME, but
-also applicable to PGP/MIME.
+Some LAMPS WG participants expressed the opinion that regardless of
+the mechanism chosen, it should not be limited to S/MIME, but also
+applicable to PGP/MIME.
+
+<!-- Suggestion KRB:
+it should be applicable to both S/MIME and PGP/MIME.
+-->
 
 This document describes the problem statement ({{problem-statement}}),
 generic use cases ({{use-cases}}) and the specification for Header
@@ -113,15 +117,20 @@ requirements that this specification is based on.
 <!-- TODO: Decide whether to add the requirements to this document or
 leave them in a separate document -->
 
-This document is in early draft state and contains a proposal to base
-the upcoming discussions on. In any case, the final solution is to be
-determined by the IETF LAMPS WG.
+This document is in early draft state and contains a proposal on which
+to base future discussions of this topic. In any case, the final
+mechanism is to be determined by the IETF LAMPS WG.
 
 {::include ../shared/text-blocks/key-words-rfc2119.mkd}
 
 
 {::include ../shared/text-blocks/terms-intro.mkd}
    
+  Note: To avoid ambiguity, this document does not use the terms
+  "Header" or "Headers" in isolation, but instead always uses "Header
+  Field" to refer to the individual field and "Header Section" to
+  refer to the entire collection; cf. {{RFC5322}}.
+
 <!-- {::include ../shared/text-blocks/handshake.mkd} -->
 <!-- {::include ../shared/text-blocks/trustwords.mkd} -->
 <!-- {::include ../shared/text-blocks/tofu.mkd} -->
@@ -131,26 +140,10 @@ determined by the IETF LAMPS WG.
 
 * PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}})
 
-* Message: An Email Message consisting of header fields
-  (collectively called "the Header Section of the message") followed,
-  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 on the
-  sending side typically determines the destination recipients by
-  reading the To, Cc and Bcc 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
   body (value), and terminated by CRLF; cf. {{RFC5322}}.
 
-  Note: To avoid ambiguity, this document does not use the terms
-  "Header" or "Headers" in isolation, but instead always uses "Header
-  Field" to refer to the individual field and "Header Section" to
-  refer to the entire collection; cf. {{RFC5322}}.
-
 * Header Section (HS): The Header Section is a sequence of lines of
   characters with special syntax as defined in {{RFC5322}}.  It is the
   (top) section of a message containing the Header Fields.
@@ -172,6 +165,27 @@ determined by the IETF LAMPS WG.
   MIME Header Fields of a Header Section that - in addition to MIME
   Header Fields - also contains non-MIME Header Fields.
 
+* Essential Header Fields (EHF): The minimum set of Header Fields an
+  Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
+
+* Message: An Email Message consisting of Header Hields
+  (collectively called "the Header Section of the message") followed,
+  optionally, by a Body; cf. {{RFC5322}}.
+
+* Transport: The entity taking care of the transport of a Message
+  towards the receiver or from the sender.
+<!-- Feedback KRB:
+  It's confusing to define transport as both an entity and process. I
+  realize that's exactly what it is, but it reads awkwardly. Suggest
+  "delivery", "transit", "transfer", or similar. The other uses of
+  "transport" are okay, just this opening sentence needs help.
+-->
+  The Transport on the
+  sending side typically determines the destination recipients by
+  reading the To, Cc and Bcc Header Fields (of the Outer
+  Message). The Transport is typically implemented by an MTA (Mail
+  Transfer Agent).
+
 * Header Protection (HP): cryptographic protection of email Header
   Sections (or parts of it) for signatures and/or encryption
 
@@ -209,9 +223,6 @@ determined by the IETF LAMPS WG.
   at the receiving side. Typically this is the same as the Inner
   Message.
 
-* Essential Header Fields (EHF): The minimum set of Header Fields an
-  Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
-
 * Protected: Protected refers to the parts of a message where
   protection measures of any Protection Level have been applied to.
 
@@ -224,7 +235,7 @@ determined by the IETF LAMPS WG.
 * Unprotected Message: A message that no protection measures of any
   Protection Levels have been applied to.
 
-* Data Minimization: Data spareness and hiding of all technically
+* Data Minimization: Data sparseness and hiding of all technically
   concealable information whenever possible.
 
 
@@ -247,7 +258,7 @@ In the following a set of challenges to be addressed:
 
 ## Privacy {#privacy}
 
-* Data Minimization, which includes data spareness and hiding all
+* Data Minimization, which includes data sparseness and hiding all
   technically concealable information whenever possible
 
 
@@ -271,9 +282,8 @@ In the following a set of challenges to be addressed:
 
 In the following, the reader can find a list of the generic use cases
 that need to be addressed for messages with Header Protection
-(HP). These use cases apply independently of whether S/MIME, PGP/MIME
-or any other technology is used to achieve HP.
-
+(HP). These use cases apply regardless of technology (S/MIME,
+PGP/MIME, etc.) used to achieve HP.
 
 
 ## Interactions {#interactions}
@@ -289,13 +299,13 @@ cf. {{main-use-case}}.
 
 ### Backward Compatibility
 <!-- explain what is not correct -->
-The sending side fully supports Header protection as specified in this
+The sending side fully supports Header Protection as specified in this
 document, while the receiving side does not support the MIME
 specification {{RFC2045}}, ff. correctly; see
 {{backward-compatibility-use-case}}.
 
 
-Note: The compatibility of legacy HP systems with this new solutions,
+Note: The compatibility of legacy HP systems with this new solution,
 and how to handle issues surrounding future maintenance for these
 legacy systems, will be decided by the LAMPS WG.
 
@@ -331,7 +341,7 @@ c)  Encryption only
 # Specification {#specification}
 
 This section contains the specification for Header Protection in
-S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
+S/MIME to update and it clarifies Section 3.1 of {{RFC8551}} (S/MIME
 4.0).
 
 Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate
@@ -488,13 +498,13 @@ to be considered, is described in
 {{I-D.autocrypt-lamps-protected-headers}}.
 
 Unlike the option described in {{option-smime-spec}}, this option does
-not use a "message/RFC822" wrapper to unambigously delimit the Inner
+not use a "message/RFC822" wrapper to unambiguously delimit the Inner
 Message.
 
 Note: More specific on Parsers (as there are two aspects here)
 
 Note: it is for further study, whether or not this option is (fully)
-compliant with the MIME standard, in particuar also {{RFC2046}},
+compliant with the MIME standard, in particular also {{RFC2046}},
 Section 5.1. (Multipart Media Type).
 <!--
 Maybe remove (as suggested by Alexey)
@@ -515,9 +525,9 @@ The MIME structure of an Email message looks as follows:
 {::include ../shared/fence-line.mkd}
 
 
-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
+The following example demonstrates how the header section and payload
+of a protected body part might appear.  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.
@@ -580,10 +590,10 @@ Message along with other MIME part(s).
 
 ### Inner Message Header Fields {#inner-msg-hf}
 
-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:
+It is RECOMMENDED 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 within the Inner Message nor
+within any other protected part of the message:
 
 * Bcc
 
@@ -598,7 +608,7 @@ The wrapper is a simple MIME Header Section followed by an empty line
 preceding the Inner Message (inside the Outer Message Body). The media
 type of the wrapper MUST be "message/RFC822" and SHOULD contain the
 Content-Type header field parameter "forwarded=no" as defined in
-{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambigously
+{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
 the Inner Message from the rest of the message.
 
 
@@ -615,11 +625,18 @@ per {{RFC8551}}.
 The following Header Fields are defined as the Essential Header Fields:
 
 * From
-* To (if present in the OrigM)
-* Cc (if present in the OrigM)
-* Bcc (if present in the OrigM, see also {{inner-msg-hf}} and {{bcc-handling}})
+
+* To (if present in the Original Message)
+
+* Cc (if present in the Original Message)
+
+* Bcc (if present in the Original Message, see also {{inner-msg-hf}}
+  and {{bcc-handling}})
+
 * Date
+
 * Message-ID
+
 * Subject
 
 <!-- if not SMTP, it is not relevant to IETF.
@@ -629,14 +646,14 @@ verify 6409 is a good reference, split to RFC5322 and RFC6409
 -->
 Some of these Header Fields are required by the submission service
 {{RFC6409}} (e.g. From, Date). Furthermore, not including certain Header
-Fields may trigger spam detection to flag the message as spam and/or
+Fields may trigger spam detection to flag the message and/or
 lead to user experience (UX) issues.
 
-For further Data Minimization the value of the Subject Header Field
+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
+preferred 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.
 
@@ -695,7 +712,7 @@ the same week. \]\]
 
 
 In certain implementations also the From, To, and/or Cc Header Field
-MAY be obfucated. Those may be replaced by e.g.
+MAY be obfuscated. Those may be replaced by e.g.
 
 * To: Obfuscated <anonymous@anonymous.invalid>
 
@@ -706,11 +723,15 @@ Such implementations need to ensure that the submission service has access to
 these Header Fields in clear text and is capable of processing 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}}).
+mixnet networks, 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.
 
+<!-- suggestion KRB:
+"Further studies of the impact that Header Field obfuscation has on
+spam filtering are needed."
+-->
 
 ### Receiving User Facing Message Header Fields {#rufm-hf}
 
@@ -768,7 +789,7 @@ Legend:
 * More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
 
 * Wrapper: MIME Header Section; with media type (message/RFC822) to
-  unambigously delimit the inner message from the rest of the
+  unambiguously delimit the inner message from the rest of the
   message.
 
 * MIME-HSp: MIME Header Section part to describe the encryption or
@@ -805,7 +826,7 @@ 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 of the Orignial Message shall be part of the
+* Which Header Fields of the Original 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; cf. {{outer-msg-hf}}.
@@ -831,9 +852,9 @@ part, which depends on the protection level selected in
 
 #### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
 
-Depending on the Protection Level selected in {{sending-side-step-1}}
-apply signature and/or encryption to the Original Message including
-the wrapper (as per {{RFC8551}}) and set the result to the message as
+Depending on the Protection Level selected in {{sending-side-step-1}},
+apply signature and/or encryption to the Original Message, including
+the wrapper (as per {{RFC8551}}), and set the result to the message as
 Outer Message Body.
 
 The resulting (Outer) Message is then typically handed over to the
@@ -844,12 +865,12 @@ Transport.
 
 ### Receiving Side Message Processing
 
-When a protected message is received the following steps are applied:
+When a protected message is received, the following steps are applied:
 
 
 #### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
 
-Depending on the protection level the received message is decrypted
+Depending on the protection level, the received message is decrypted
 and/or its signature is checked as per {{RFC8551}}.
 
 
@@ -859,36 +880,36 @@ The Receiving User Facing Message is constructed according to
 {{rufm-hf}}.
 
 The resulting message is handed over for further processing, which
-typically involves rendering it to the user.
+typically involves rendering it for the user.
 
 
-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.
+Note: Further study is needed to determine whether or not the Outer
+      Message Header Section, as received from the Transport, is
+      preserved for the user, and if so, how this is to be achieved.
 
 
 ## Backward Compatibility Use Case {#backward-compatibility-use-case}
 
-{{I-D.autocrypt-lamps-protected-headers}} describes a possibility to
+{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
 achieve backward compatibility with existing S/MIME (and PGP/MIME)
-implementations unaware of this specification (Legacy Display). It
+implementations that predate this specification (Legacy Display). It
 mainly focuses on email clients that do not render emails using header
-protection (nicely) and may confuse the user. While this has been
-observed occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of
-this problem with S/MIME implementations is still unclear. (Note: At
-this time, none of the samples in
-{{I-D.autocrypt-lamps-protected-headers}} applies header protection as
+protection (in a user friendly manner) and may confuse the user. While
+this has been observed occasionally in PGP/MIME (cf. {{RFC3156}}), the
+extent of this problem with S/MIME implementations is still
+unclear. (Note: At this time, none of the samples in
+{{I-D.autocrypt-lamps-protected-headers}} apply header protection as
 specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
 Type "message/RFC822".)
 
 Should serious backward compatibility issues with rendering at the
-receiver reveal, the Legacy Display format described in
+receiver be discovered, the Legacy Display format described in
 {{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
-mitigate those (backward compatibility use case).
+mitigate those issues (cf. {{backward-compatibility-use-case}}).
 
 Another variant of backward compatibility has been implemented by pEp
 {{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
-has implemented this for PGP/MIME (but not yet S/MIME).
+has implemented this for PGP/MIME, but not yet S/MIME.
 
 
 # Security Considerations
@@ -911,10 +932,11 @@ This document requests no action from IANA.
 # Acknowledgments
 
 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: add DKG either to authors or to Acknowledgements -->
+helpful comments and suggestions for this document: Berna Alp, Claudio
+Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,
+Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
+Chuang.  <!-- TODO: add DKG either to authors or to Acknowledgements
+-->
 
 --- back
 
@@ -939,26 +961,25 @@ header field may appear in up to three different variants:
    field, which depends on the implementation:
 
    a) One message for each recipient in the Bcc header field
-      separately with a Bcc header field containing only the address
-      of the recipient it is sent to
+      separately, with a Bcc header field containing only the address
+      of the recipient it is sent to.
 
    b) The same message for each recipient in the Bcc header field with
       a Bcc header field containing an indication such as "Undisclosed
-      recipients" (but no addressees)
+      recipients", but no addresses.
       
    c) The same message for each recipient in the Bcc header field
       which does not include a Bcc header field (this message is
-      identical to 1. / cf. above)
+      identical to 1. / cf. above).
 
 3. The message stored in the 'Sent'-Folder of the sender, which
    usually contains the Bcc unchanged from the original message,
-   i.e. with all recipient addresses.
+   i.e., with all recipient addresses.
 
-The most privacy preserving of the alternatives (2a, 2b, and 2c)
-is to standardize 2a, as in the other
-cases (2b and 2c) information about hidden recipients is revealed via
-keys. In any case the message has to be cloned and adjusted depending
-on the recipient.
+The most privacy preserving method of the alternatives (2a, 2b, and
+2c) is to standardize 2a, as in the other cases (2b and 2c),
+information about hidden recipients is revealed via keys. In any case,
+the message has to be cloned and adjusted depending on the recipient.
 
 
 
@@ -980,7 +1001,7 @@ on the recipient.
      before publication. \]\]
 
 * Ensure "protected header" (Ex-Memory-Hole) option is (fully)
-compliant with the MIME standard, in particuar also {{RFC2046}},
+compliant with the MIME standard, in particular also {{RFC2046}},
 Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.