From 8046f8f46743bb3e6dcb86501d37b21cd78bed77 Mon Sep 17 00:00:00 2001 From: Kelly Bristol Date: Mon, 6 Jul 2020 03:46:55 -0500 Subject: [PATCH] KRB LAMPS draft finished review --- ...s-header-protection-00-pre20200628-KRB.txt | 56 ++++++++++--------- 1 file changed, 29 insertions(+), 27 deletions(-) diff --git a/ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628-KRB.txt b/ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628-KRB.txt index 32f907a0..691ac0da 100644 --- a/ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628-KRB.txt +++ b/ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200628-KRB.txt @@ -800,7 +800,7 @@ Internet-Draft Header Protection S/MIME June 2020 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 obfucated. [KRB: "obfuscated". Please fix all instances.] Those may be replaced by e.g. o To: Obfuscated anonymous@anonymous.invalid [1] @@ -808,10 +808,10 @@ Internet-Draft Header Protection S/MIME June 2020 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 netwerks [KRB: "networks". Please fix all instances.], 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. [KRB: suggest "Further studies of the impact that Header Field obfuscation has on spam filtering are needed." If adversely is in parentheses, it implies that some impacts may be positive. Not sure if that's the intent of your statement, here.] 4.1.5. Receiving User Facing Message Header Fields @@ -892,6 +892,8 @@ Internet-Draft Header Protection S/MIME June 2020 o MIME-HSp: MIME Header Section part to describe the encryption or signature as per [RFC8551] + [KRB: You may wish to consider putting this before the example diagram.] + Hoeneisen & Melnikov Expires December 30, 2020 [Page 16] @@ -928,7 +930,7 @@ Internet-Draft Header Protection S/MIME June 2020 the message? This depends on user request and/or local policy as well as availability of cryptographic keys. - o Which Header Fields of the Orignial Message shall be part of the + o Which Header Fields of the Orignial [KRB: "Original". Please fix all instances.] 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. Section 4.1.4. @@ -960,9 +962,9 @@ Internet-Draft Header Protection S/MIME June 2020 4.1.7.3. Step 3: Apply Protection to the Original Message - Depending on the Protection Level selected in Section 4.1.7.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 + Depending on the Protection Level selected in Section 4.1.7.1 [KRB: add comma here] apply + signature and/or encryption to the Original Message [KRB: add comma here] including the + wrapper (as per [RFC8551]) [KRB: add comma here] and set the result to the message as Outer Message Body. The resulting (Outer) Message is then typically handed over to the @@ -972,11 +974,11 @@ Internet-Draft Header Protection S/MIME June 2020 4.1.8. Receiving Side Message Processing - When a protected message is received the following steps are applied: + When a protected message is received [KRB: add comma here] the following steps are applied: 4.1.8.1. Step 1: Decrypt message and/or check signature - Depending on the protection level the received message is decrypted + Depending on the protection level [KRB: add comma here] the received message is decrypted and/or its signature is checked as per [RFC8551]. 4.1.8.2. Step 2: Construct the Receiving User Facing Message @@ -985,23 +987,23 @@ Internet-Draft Header Protection S/MIME June 2020 Section 4.1.5. The resulting message is handed over for further processing, which - typically involves rendering it to the user. + typically involves rendering it to [KRB: "to" -> "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. + for the user. [KRB: suggest "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."] 4.2. Backward Compatibility Use Case - [I-D.autocrypt-lamps-protected-headers] describes a possibility to + [I-D.autocrypt-lamps-protected-headers] describes a possibility [KRB: suggest "possible way"] to achieve backward compatibility with existing S/MIME (and PGP/MIME) - implementations unaware of this specification (Legacy Display). It + implementations unaware of this specification (Legacy Display). [KRB: This reads really awkwardly. Suggest "created prior to this specification"] It mainly focuses on email clients that do not render emails using - header protection (nicely) and may confuse the user. While this has + header protection (nicely) [KRB: What do you mean by "nicely"? Do you mean that they do not render these particular emails 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] applies header protection as + [I-D.autocrypt-lamps-protected-headers] applies[KRB: "apply"] header protection as @@ -1015,13 +1017,13 @@ Internet-Draft Header Protection S/MIME June 2020 Type "message/RFC822".) Should serious backward compatibility issues with rendering at the - receiver reveal, the Legacy Display format described in + receiver reveal [KRB: "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 (backward compatibility use case) [KRB: Not sure why the parenthetical is here. I'd just end the sentence with "...as a basis to mitigate those issues."]. 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). + implemented this for PGP/MIME (but not yet S/MIME) [KRB: This parenthetical should be a regular part of the sentence, i.e., not in parentheses. Add a comma after PGP/MIME.]. 5. Security Considerations @@ -1146,7 +1148,7 @@ Internet-Draft Header Protection S/MIME June 2020 [1] mailto:anonymous@anonymous.invalid -Appendix A. Additional information +Appendix A. Additional information [KRB: I've noticed in these lists, you're not ending with a period. Periods should still be used.] A.1. Stored Variants of Messages with Bcc @@ -1161,16 +1163,16 @@ A.1. Stored Variants of Messages with Bcc 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 [KRB: add comma here] with a Bcc header field containing only the address of + the recipient it is sent to [KRB: add period here] 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) + "Undisclosed recipients" (but no addressees) [KRB: Again, not sure why this last part is in parentheses. Get rid of those, add a comma after recipients, and add period at the end of the sentence.] 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) [KRB: add period here] @@ -1181,11 +1183,11 @@ Internet-Draft Header Protection S/MIME June 2020 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. [KRB: add comma here] with all recipient addresses. - The most privacy preserving 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 + The most privacy preserving [KRB: add the word "method"] is to standardize 2a, as in the other + cases (2b and 2c) [KRB: add comma here] information about hidden recipients is revealed via + keys. In any case [KRB: add comma here] the message has to be cloned and adjusted depending on the recipient. Appendix B. Document Changelog