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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Daniel Migault <[e-mail]>
> Sent: Sunday, June 24, 2018 8:31 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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.
> 
> 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.

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

'remove mention of AES-192 CBC'

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

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.

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

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

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.

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

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.

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

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

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

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.

> 
> idem for section 4.4