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

From: Ben Campbell <[email-masked]>
Date: Mon, 02 Jul 2018 18:07:44 -0700

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 3 Jul 2018 09:40:45 -0700

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

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

> 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

> s/understanding/understands

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

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

Fixed - I used the last one

> entity can be sub-part or sub-parts of a message?

Yes.  It can be one, two, a tree or the entire message.

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

>    algorithms, use the .Authenticated Enveloped structure for these

Fixed

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

>       the message.": The antecedent of "them" is ambiguous.

s/them as a recipient/the second recipient/

>       party could have seen the resulting CEK."

I have never gotten which/that correct 

>       party could have seen the resulting CEK."

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.

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

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

>    attack on the encryption key is necessarily required."

Fixed

> I don't think the "error" is the "attack". perhaps s/"is an error"/"involves an

/is an error/is due to an error/

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

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Jul 2018 17:05:47 -0400

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

It would be safe to allow the key for the key wrap algorithm to be larger  (e.g., AES-256  key wrap algorithm with AES-128 content encryption algorithm).

That said, a long time ago, we settled on this language because it was very difficult to come up with rules if the key wrap algorithm and the content encryption algorithm were using very different underlying ciphers.

Russ

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Jul 2018 23:38:07 -0500

> On Jul 3, 2018, at 11:40 AM, Jim Schaad <[email-masked]> wrote:
> 
> 
> 

Okay, I think the issue is the antecedent of “this” in “… MAY enforce this” is ambiguous. I read it as referring to the previous sentence’s statement that both key sizes MUST be supported.

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

I suggest that adding some text to that effect, even if you keep the SHOULD for now.

[…]

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

Ah, I was trying to read it as “… algorithm was changed to a MUST-implement key wrap algorithm”. The problem was not the comma so much as “changed to a MUST implement”. I suggest  changing that to “changed to be MUST implement”. (I agree on the period.)

[…]

> Yes.  It can be one, two, a tree or the entire message.

How about “A MIME entity can one or more sub-parts of a MIME message, or a whole MIME message with all of its sub-parts”.

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

yes.

[…]
> How can it be a comma splice if there is no comma?

Ah, that was a copy-paste error. I meant this: "
 S/MIME implementations almost universally use ephemeral-static rather
   than static-static key agreement and do not use a shared secret for
   encryption, this means that the first precondition is not met.
“

[…]

Thanks!

Ben.