[Gen-art] Genart last call review of draft-ietf-lamps-header-protection-20

[Peter Yee via Datatracker <[e-mail]>]

Reviewer: Peter Yee
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-lamps-header-protection-20
Reviewer: Peter Yee
Review Date: 2024-04-12
IETF LC End Date: 2024-03-25
IESG Telechat date: Not scheduled for a telechat

Summary: This is a comprehensive draft describing how email header protection
can be done when sending cryptographically protected emails, with respect given
to legacy MUAs, rendering considerations, security pitfalls, and other gotchas.
The examples are extensive (bravo for making them available online!) and should
be really helpful to implementers, although I did not attempt to verify them in
the slightest. I did read through many of them and I am glad the table of
contents makes it easy to find the right example without extensive scrolling or
grepping. The document has a set of nits that I’ve documented below but
otherwise looks good to go. These are really minor things I raise to save the
RFC Editor some work. [Ready with Nits]

Major issues: None

Minor issues: None

Nits/editorial comments:

General:

Page 1, title (and elsewhere): RFC Editor preferred usage is Email (titles) or
email (body text). https://www.rfc-editor.org/materials/terms-online.txt. I do
realize that there’s quite a history of using “e-mail” with the related
protocols, so I won’t argue in the slightest if you prefer to retain “E-mail”
and “e-mail” in the document.

Page 6, 1st paragraph, 2nd sentence (and elsewhere): Change
“cryptographically-protected” to “cryptographically protected”. Adverbs ending
in “ly” and the following adjective are not joined with a hyphen. I’d advise
looking for “ly-“ in the document, but do not do a global find-and-replace
because “Reply-To” and its ilk are correct as written. List of adverbs that you
might find helpful: [Cc]ryptographically, fully, specially, previously,
[Ii]mplicitly, widely, and publicly.

Change “timezone” to “time zone” throughout the document.

“E.g.” and “e.g.” should be followed by a comma and a single space character.
Usage in the document is inconsistent.

Use of header field names is inconsistent. Sometimes they are written as “To”,
other times as “To:”. Sometimes they are followed somewhere in the sentence by
“header” or “Header Field[s]”, other times they are treated as proper names.

Look for “a encrypted” and change to “an encrypted”. There are several of
these, mostly in Appendix B, I believe.

Specific:

Page 7, section 1.1, 1st paragraph, 2nd sentence: delete the comma after
“MUAs”. This sentence (and many others in the document) have a compound
predicate, so the comma is not appropriate before the coordinating conjunction.
I’ll point these out individually because I can’t think of a good regexp that
accurately finds them.

Page 7, section 1.1, 3rd paragraph, 2nd sentence: I think you can omit the
comma after “Payload”.

Page 9, 1st partial paragraph, 2nd sentence: change “backward-compatible” to
“backward compatible”.

Page 9, 1st full paragraph, 2nd sentence: the wording “message cannot behave”
strikes me as odd. Messages don’t behave. They are processed, including by
MUAs. They are transmitted. They are rendered. But they don’t behave. Perhaps
reword the second part of the sentence from “the message cannot behave entirely
identically to a Legacy MUA” to “a message cannot be rendered entirely
identically to how a Legacy MUA does so”.

Page 10, 4th paragraph, 1st sentence: omit the open parenthesis before
“[PGPCONTROL]”.

Page 11, section 1.8, 6th bullet point, 2nd sentence, insert “a” before
“Message”.

Page 11, section 1.8, 7th bullet point: consider changing “for” to “via” or “by
means of”.

Page 17, 3rd bullet item: RFC Editor preferred usage
(https://www.rfc-editor.org/materials/terms-online.txt) is “ASCII” instead of
“US-ASCII”, but I do understand that the actual charset is called us-ascii.
Your call.

Page 26, section 2.3.6, title: the title says “Choosing”, but the section
doesn’t give insights into making such a choice. It only says that a compatible
MUA must be able to generate Injected Headers. Is there some discussing missing
here?

Page 26, section 2.4.1, 1st paragraph, 1st sentence: I'm not sure I would
describe this as conservative because it depends on what you're being
conservative about. The least resources used? The least information leaked? The
most likely to be delivered? Please clarify here and perhaps in the other
places in the document where something is described as conservative.

Page 27, 1st partial paragraph: the delete the comma after “protections”.

Page 27, section 2.4.4, 1st paragraph, 2nd sentence:  delete the first “or”.

Page 30, 1st sentence: change “one the following” to “one of the following”.

Page 32, section 2.5.3.3, 3rd paragraph, 2nd sentence: append a comma after
“downloaded”.

Page 33, section 2.5.3.3.3, 1st paragraph after the bullet point, 2nd sentence:
change the lone “b” to “be”.

Page 35, section 2.5.5.1, last paragraph, last sentence: delete the comm after
“error”.

Page 36, section 2.5.5.2, 1st paragraph, 1st sentence: change “e-mail based” to
“e-mail-based”. Change “within message” to “within the message”.

Page 38, section 2.5.9, 1st paragraph, 1st sentence: I’m not sure why there are
so many uses of “and” here. I recommend deleting all but the last one and
insert commas instead.

Page 39, section 2.5.10, 1st paragraph, 1st sentence: delete the comma after
“transit”.

Page 40, section 2.5.11, 1st paragraph, 2nd sentence: arguably, delete the
comma after “Fields”.

Page 41, 1st paragraph, 3rd sentence: delete the comma after “Or”.

Page 42, section 3.1, 3rd paragraph: change “make” to “set”. Delete the comma
after “default”.

Page 43, 1st paragraph, last sentence: delete the comma after “HCP”.

Page 44, section 4.1, 3rd bullet item: change “An” to “A”.

Page 46, section 5, 2nd paragraph, 1st sentence: I’m not quite clear on what
the antecedent of “these protections” is. Do you mean, from the previous
paragraph, “mechanism”, “technologies”, or “confidentiality, authenticity, and
integrity”?

Page 48, last paragraph, 2nd sentence: insert “the” before “recipient”.

Page 48, last paragraph, last sentence: delete the comma after “agents”.

Page 54, section 8: remove a spurious space after “E.”.

Page 58, Appendix A, title: change “some” to “Some”.

Page 58, section A.2, 2nd bullet item: change “subject” to “Subject”.

Page 58, section A.2, 3rd bullet item: change “subject” to “Subject”, change
“date” to “Date”, change “from” to “From”, and “to” to “To”. Insert “and”
before “To”.

Page 58, section A.2, 7th bullet item: change “subject” to “Subject”.

Page 59, section A.3, 2nd and 3rd bullet item: I suppose you might as well put
periods after there if you’re going to put one at the end of the 1st bullet
item. Perhaps, just remove them all.

Page 59, section A.3, 4th through 10th bullet items: capitalize the first word
in each bullet item as you’ve done elsewhere.

Page 59, section A.3, 4th through 6th bullet item: change first use in each
bullet item of “subject” to “Subject”, probably.

Page 60, section A.4, 1st bullet item: insert “and” before “To”.

Page 186, section C.1.2.1, 2nd bullet item: delete the comma.

Page 187, section C.1.2.2, 1st paragraph, 2nd sentence: change “a application”
to “an application”.

Page 191, section C.2.2.1, 1st sentence: change “Consesquently” to
“Consequently”.

Page 192, section C.2.2.2, 1st paragraph, 2nd sentence: change “a application”
to “an application”.