Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
draft-ietf-lamps-rfc5751-bis-12

Note: This ballot was opened for revision 10 and is now closed.

(Ben Campbell) Yes

Comment (2018-07-02 for -10)
No email
send info
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"?

Alissa Cooper Yes

Comment (2018-07-05 for -10)
No email
send info
In Appendix B:

This is a sentence fragment: "the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect. 

also s/that it it/that is it/

(Terry Manderson) Yes

Alexey Melnikov Yes

Comment (2018-07-01 for -10)
No email
send info
I believe S/MIME needs updated rules for header protection, but this can be handled as a separate draft that updates this one.

(Eric Rescorla) Yes

Adam Roach Yes

Comment (2018-07-02 for -10)
No email
send info
Thanks to everyone who put work into updating this document. I have one comment
that is either substantive or me just being confused, and several editorial
nits.

---------------------------------------------------------------------------

§3.5.3.2:

>  The values to be placed in the micalg parameter SHOULD be from the
>  following:
>
>   Algorithm Value Used
>   MD5       md5
>   SHA-1     sha-1
>   SHA-224   sha-224
>   SHA-256   sha-256
>   SHA-384   sha-384
>   SHA-512   sha-512
>   Any other (defined separately in algorithm profile or "unknown" if
>             not defined)

The example then goes on to demonstrate the use of "micalg=sha-1".  This is
probably a misunderstanding on my part, but I thought that this document was
intending to mark MD5 and SHA-1 as historic for digesting content (cf. §1.7
and §B.1). Wouldn't that mean they should be annotated as deprecated in some
way here? I would have also expected the example to use sha-256 or sha-512.

---------------------------------------------------------------------------

§2.2:

>  -  .  SHOULD support RSASSA-PSS with SHA-256.

There appears to be an extra "." at the beginning of this bullet

---------------------------------------------------------------------------

§3.1:

>  S/MIME is used to secure MIME entities.  A MIME message is composed
>  of a MIME header and a MIME body, the body can consist of a single
>  part or of multiple parts.

Nit: "...MIME body. The body can..."

---------------------------------------------------------------------------

§3.3:

>  The
>  Enveloped-Only structure does not support authenticated symmetric
>  algorithms, use the .Authenticated Enveloped structure for these
>  algorithms.

Two nits: "...symmetric algorithms. Use the Authenticated..."
                                  ^        ^
---------------------------------------------------------------------------

§6:

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

Nit: "...encryption. This means..."

Ignas Bagdonas No Objection

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2018-07-19 for -11)
No email
send info
Thanks for addressing the discuss point; original ballot comments retained below.

I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Should the Abstract/Introduction mention that AEAD encryption provides non-malleability?

Section-by-Section comments follow.

Section 1

nit: Does FAX need to be all-caps?

Section 1.1

   In order to create S/MIME messages, an S/MIME agent MUST follow the
   specifications in this document, as well as the specifications listed
   in the Cryptographic Message Syntax document [CMS], [RFC3370],
   [RFC4056], [RFC3560], and [RFC5754].

nit: is that "[CMS] documents" plural?

I have been observing growing unease with Postel's Principle over time;
it's less clear that blindly repeating it is the best position to take.

Section 1.2

BER does not appear to be used in the body text?

Section 1.5

I recognize this is historical text, but to modern readers, there is not a
single "the AES symmetric encryption algorithm" -- there are CBC modes and
GCM modes, and v4.0 distinguishes between them.  Should this text get
clarified about the difference?

Section 2.5.2

   The OIDs that correspond to algorithms SHOULD use the same OID as the
   actual algorithm, except in the case where the algorithm usage is
   ambiguous from the OID.  For instance, in an earlier specification,
   rsaEncryption was ambiguous because it could refer to either a
   signature algorithm or a key encipherment algorithm.  In the event
   that an OID is ambiguous, it needs to be arbitrated by the maintainer
   of the registered SMIMECapabilities list as to which type of
   algorithm will use the OID, and a new OID MUST be allocated under the
   smimeCapabilities OID to satisfy the other use of the OID.

(nit?) "the other use" implies there will only ever be one other (two
total), which is perhaps needlessly limiting.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

   In order to protect outer, non-content-related message header fields
   (for instance, the "Subject", "To", "From", and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
   wrapper in order to apply S/MIME security services to these header
   fields.  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.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

   In the case where S/MIME implementations can determine that all
   intended recipients are capable of handling inner (all but the
   outermost) binary MIME objects SHOULD use binary encoding as opposed
   to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

   but not signed messages does not provide for data integrity.  The
   Enveloped-Only structure does not support authenticated symmetric
   algorithms, use the .Authenticated Enveloped structure for these
   algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

   Some cryptographic algorithms such as RC2 offer little actual
   security over sending plaintext.  Other algorithms such as TripleDES,
   provide security but are no longer considered to be state of the art.
   S/MIME requires the use of current state of the art algorithms such
   as AES and provides the ability to announce starter cryptographic
   capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

   Modification of the ciphertext in EnvelopedData can go undetected if
   authentication is not also used, which is the case when sending
   EnvelopedData without wrapping it in SignedData or enclosing
   SignedData within it.  This is one of the reasons for moving from
   EnvelopedData to AuthEnvelopedData as the authenticated encryption
   algorithms provide the authentication without needing the SignedData
   layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

   mail clients deal with HTML and multipart/mixed messages.  Clients
   MUST require that a text/html content type is a complete HTML
   document (per [RFC1866]).  Clients SHOULD treat each of the different
   pieces of the multipart/mixed construct as being of different
   origins.  Clients MUST treat each encrypted or signed piece of a MIME
   message as being of different origins both from unprotected content
   and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

   This appendix contains a number of references to documents that have
   been obsoleted or replaced, this is intentional as frequently the
   updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

   -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection