[lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-lamps-rfc5751-bis-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "yes", but have some minor comments substantive comments and a
number of editorial comments. I mainly reviewed the diff from RFC 5751.

Substantive Comments:

§2.3, 2nd to last paragraph: I don't understand what it means to say recipients
MAY enforce a "MUST be supported" requirement. Am I correct to assume the "MUST
use the weaker" only applies if the sender used both key-wrap algorithms?

§3.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't seem to add
information, but it does undermine the SHOULD that immediately follows. (I'd
count this as an editorial comment, but I think undermining a SHOULD is a
material issue.)

Editorial Comments:

- IDNits complains about some unused references. Please check. (They may be due
to the specification-group references, which I think are fine).

§1.5: I have trouble parsing the first paragraph. Is the comma in "... MUST
implement, key wrap algorithm... " intentional?

§2.2, Receiving agent requirements, 4th bullet: Spurious "." and white space at
beginning.

§2.5.2: "The presence
   of an algorithm based SMIME Capability attribute in this sequence
   implies that the sender can deal with the algorithm as well as
   understanding the ASN.1 structures associated with that algorithm."
s/understanding/understands

§2.5.3, 2nd paragraph: "If a signature is detected to violate
   these requirements, the signature SHOULD be treated as failing."

"detected to violate" is awkward. Perhaps "determined to violate", "detected to
be violating", or "detected as violating"?

§3.1:
- first paragraph: "A MIME entity can be a sub-part, sub-parts of a
   MIME message, or the whole MIME message with all of its sub-parts."

I'm not sure how to parse the first comma. Is the intent of that part that the
entity can be sub-part or sub-parts of a message?

 - 2nd to last paragraph: " It is up to the receiving client to decide how to
 present
   this "inner" header along with the unprotected "outer" header.  It is
   RECOMMENDED that a distinction be made between the location of the
   header."
The last sentence partially contradicts the first one. Also, can the last
sentence be phrased in active voice, to strengthen the connection to the client
as the actor?

§3.3, first paragraph: "The
   Enveloped-Only structure does not support authenticated symmetric
   algorithms, use the .Authenticated Enveloped structure for these
   algorithms. "
Comma splice.

§6:

- " Many people assume that the use of an authenticated encryption
   algorithm is all that is needed to be in a situation where the sender
   of the message will be authenticated."
Convoluted sentence. The phrase "needed to be in a situation where" seems like
a complicated way of expressing something like "needed to consider the sender
to be authenticated"

- "... create a message that the first recipient would
      believe is from the sender by stripping them as a recipient from
      the message.": The antecedent of "them" is ambiguous.

- "A direct path needs to exist from the starting key to the key used
      as the content encryption key (CEK) which guarantees that no third
      party could have seen the resulting CEK."
s/which/that

- "A direct path needs to exist from the starting key to the key used
      as the content encryption key (CEK) which guarantees that no third
      party could have seen the resulting CEK."
Comma splice.

- "There
   is a document [RFC6278] which defined how to use static-static key
   agreement with CMS so that is readably doable. "
s/which/that. Also, the _existing_ "that" has an unclear antecedent.

- "New key agreement algorithms that directly
   created the CEK without creating an intervening KEK would need to be
   defined."

Should "would need" simply be "need"?

- "Compression oracle attacks require an adaptive
   input to the process and attack the unknown content of a message
   based on the length of the compressed output, this means that no
   attack on the encryption key is necessarily required."
Comma splice.

- "The other attack that is highlighted in [Efail] is an error in how
   mail clients deal with HTML and multipart/mixed messages. "
I don't think the "error" is the "attack". perhaps s/"is an error"/"involves an
error"?

- Appendix D: "Some of the examples in this document were stolen from
[RFC4134]."

Can this say something like "copied from" or "borrowed from"?