[secdir] Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10

[Daniel Migault <[e-mail]>]

Reviewer: Daniel Migault
Review result: Ready

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with (tiny) nits

Yours,
Daniel

--- 1.7. Changes for S/MIME v4.0

"""
Update the content encryption algorithms (Section 2.7 and Section 2.7.1.2): Add
AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as
historic. """

In section AES-CBC has its status set to MUST-. "removed" sounds to me as MUST
NOT status. In that case, I believe sunsetting or something equivalent might be
more appropriated than removed.

TripleDES is mentioned in section 2.7.2 I believe it would be appropriated to
also mention these algorithms in section 2.7 with a MUST NOT.

It might be also appropriated to mention that these algorithm concerns the
messages being sent and received while old emails may still be decrypted with
there old algorithms.

Note that the two latest comments are being discussed in the review thread of
version 07.

I understand that AES-CBC is being mentioned for compatibility reasons with
older S/MIME versions, but that AES-CTR as well as enveloped-data type are
expected to be rolled out in the next or next next next version.

--- section 2.7.1

"""
Before sending a message, the sending agent MUST decide whether it is willing
to use weak encryption for the particular data in the message. If the sending
agent decides that weak encryption is unacceptable for this data, then the
sending agent MUST NOT use a weak algorithm. The decision to use or not use
weak encryption overrides any other decision in this section about which
encryption algorithm to use. """

I am a bit worried by the text that seems to provide an enable weak encryption
check box. Maybe it should be stated that weak encryption SHOULD NOT be used.

(same in section 2.7.2)

--- 3.1.2 Transfer encoding

I see the 7-bit transfer encoding as a legacy mechanisms. While this seems to
me out of scope of S/MIME to roll it out and make binary encoding as the base,
I am wondering if that is something to consider for next version of MIME for
example ?

--- 3.5.3.2 Creating a multipart/signed Message

I believe that MD5 SHA1, SHA224 are not deprecated to verify the old messages,
but should not be used for the new sent/received messages.

--- 4 Certificate Processing

I am wondering if some recommendations so the security associated to the
certification is greater or equal to teh security associated to the message. At
least when the comparison is possible.

---section 4.2

It is strange not to have MUST for 2048 <= key size <= 4096. I understand why,
but it also means that we may not have interoperability between the Signature
Generation and Signature Verification.

idem for section 4.4