Subject: Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10

From: Daniel Migault <[email-masked]>
Date: Sun, 24 Jun 2018 20:30:47 -0700

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 29 Jun 2018 12:06:38 -0700

> -----Original Message-----
> From: Daniel Migault <[email-masked]>
> Sent: Sunday, June 24, 2018 8:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10
> 
> 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.
> 
> 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.

This is not to be a MUST NOT, I have changed to the text to

'remove mention of AES-192 CBC'

> also mention these algorithms in section 2.7 with a MUST NOT.

There is  not a MUST NOT on TripleDES at this time.  There may still be cases where TripleDES may need to be used to send messages to older implementations of S/MIME.  All we are doing is saying - make sure that the user knows that this may not be a good idea.  There are no known attacks against TripleDES that I am aware of.

> messages being sent and received while old emails may still be decrypted
> with there old algorithms.

This is the entire point of the appendix B.  

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

There is zero chance that AES-CTR is going to be rolled out at any time in the future.  The trend is to go to AEAD algorithms only.

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

If you do not use a weak encryption algorithm you might not be able to send the message at all.  Bad encryption is considered to be better than no encryption.

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

It would be great if the world had all 8-bit clean for sending and receiving messages.  Even if MIME were updated to it is not clear that S/MIME should ever change it's recommendation as hitting a single 7-bit only gateway completely destroys the message.
I don't see any changes in this document.

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

That is true, however this does not change the set of values that are placed in the micalg parameter.  

> least when the comparison is possible.

This is an interesting idea, however I am unsure how to even go about making this statement.  Trying to set levels of security between different algorithms is fraught with danger.   Additionally, what would you do with the message if there was a difference in the comparison  should it be marked as insecure?  

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

I understand what you are saying.  However an implementation that only does RSA keys of 2048 for signature generation would not be compliant under a MUST and is for a SHOULD.   Also an implementation that only creates EdDSA signatures but cannot create an RSA signature is fine w/ SHOULD but not w/ MUST.