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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Sent: Monday, July 2, 2018 6:08 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Russ Housley
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with
> COMMENT)
> 
> 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?

No, it is possible that one could use a 128-bit content encryption algorithm, but use a 256-bit key wrap algorithm (or the reverse).  The text would apply in this case and allows for a recipient to avoid the MUST be the same length requirement if they wish.

> 
> §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.)

There have actually been some people who have requested that this SHOULD be removed from the document altogether.  The feeling by some is that in the last 20 years the number of gateways which are not 8-bit compatible is now sufficiently small that there is no reason to even recommend that 7-bit transfer encoding be used here.  I don't really have any problems with undermining the SHOULD, but I would want to see some numbers about 8-bit ubiquity before removing the requirement completely.

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

Done - With any luck the V3 xml2rfc will do a better job of letting one do these group references.  

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

Yes that comma is intentional.  However I am going to change it to a period.

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

Fixed

> 
> §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

Fixed - but I made it singular which I think is grammatically correct.

> 
> §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"?

Fixed - I used the last one

> 
> §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?

Yes.  It can be one, two, a tree or the entire 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?

Given the security difference between headers, it is RECOMMENDED that client provide a distinction between header fields depending on where they are located.

Is that better?

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

Fixed

> 
> §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"

Many people assume that the use of an authenticated encryption algorithm is all that is needed for  the sender of the message 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.

s/them as a recipient/the second recipient/

> 
> - "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

I have never gotten which/that correct 

> 
> - "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.

How can it be a comma splice if there is no comma?

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

> 
> - "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.

There is a document <xref target="RFC6278"/> which defined how to use static-static key agreement with CMS, so the first precondition can be met.

> 
> - "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"?

I think "would need" is correct here.  This only needs to happen if you are interested in doing this.  There is no direct requirement at the moment to do so.

> 
> - "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.

Fixed

> 
> - "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"?

/is an error/is due to 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"?

Hey - I just stole them - but changed to copied.