Last Call Review of draft-ietf-lamps-rfc5751-bis-07
review-ietf-lamps-rfc5751-bis-07-secdir-lc-migault-2018-04-27-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-lamps-rfc5751-bis-07-secdir-lc-migault-2018-04-27

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 Has Minor Nits


Please find my comments while reading the draft.

Yours, 

Daniel


1.  Introduction

As a supplementary service, S/MIME provides for message
   compression.

maybe : 
As a supplementary service, S/MIME provides message
   compression.


1.3.  Conventions Used in This Document

The term RSA in this document almost always refers to the PKCS#1 v1.5
   RSA signature or encryption algorithms even when not qualified as
   such.

I am not sure format would not be more appropriated than algorithm, so
maybe:

The term RSA in this document almost always refers to the PKCS#1 v1.5
   RSA signature or encryption *format* even when not qualified as
   such.


2.3.  KeyEncryptionAlgorithmIdentifier

When ECDH ephemeral-static is used, a key wrap algorithm is also
   specified in the KeyEncryptionAlgorithmIdentifier [RFC5652].  The
   underlying encryption functions for the key wrap and content
   encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for
   the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
   with AES-128 content encryption algorithm). 

I understand the recommendation for a sending agent, but it seems that
additional text should be provided in order to describe the behavior of
the receiver. I am wondering if the receiver is expected to reject the
message or whether it should assume the associated protection is the
least of the two. Maybe specifying this is only for sending agent may
also clarify this.  

2.4.4.  AuthEnvelopedData Content Type

This content type does not provide
   authentication or non-repudiation.

is a really helpful clarification ;-) Maybe it could be helpful to use
the same formulation for section 2.4.2.  SignedData Content Type by
replacing:

Applying a
   signature to a message provides authentication, message integrity,
   and non-repudiation of origin.


This content type provides provides authentication, message integrity,
and non-repudiation of origin. A sender signs the message with its own
private key and shares public part of it with the recipient to validate
the signature.  

2.5.  Attributes and the SignerInfo Type

It would probably ease the reading and clarifying the purpose of the
SignerInfo's attribute. Typically, some of them might necessary to
validate the received message, while others are informational in
prevision of a response. This is clarified later in the document but
could be introduced here. I also believe that would be good to also
include that there is a bootstrapping issue that is solved by the
compliance of the implementations in supporting the recommended
algorithms. 

A reference to section 2.7 may be useful as this section clarifies how
the sending agent uses these information - at least for the encryption.

2.5.1.  Signing Time Attribute
  
The message originator has not been specified before, it may be good to
clarify how it differs from the sender. It may also be good to specify
how this value is being used - against replay attacks.  section 2.7.1
provides some indications of the expected usage of the signing time
attribute but it seems more associated to the capabilities.

2.5.2.  SMIME Capabilities Attribute

A client does not have to list every capability it
   supports, and need not list all its capabilities so that the
   capabilities list doesn't get too long.

It might be worth providing a recommendation on what too long means,
especially as a resulting list of capabilities is (expected) to be
relatively short compared to the message itself - but I might be wrong.
My reading of this attribute - and again I might be wrong - is that it
would be useless if implementations would follow the cryptographic
recommendations.  It is mostly useful to have non updated senders to
received responses from up-to-date responders. In addition, this
information is likely cached and as such may not be unnecessarily be
repeated. Wouldn't a MAY be more appropriated ?

Note also that while we have some cryptographic recommendations for RSA,
I would have expected a table summarizing the cryptographic
recommendations with other algorithms than RSA.

2.5.3.  Encryption Key Preference Attribute

 This attribute is designed to
   enhance behavior for interoperating with those clients that use
   separate keys for encryption and signing.

Maybe that would be good to position this attribute versus the keyusage
when certificate are used to split the usage of each keys. I am
wondering if a recommendation could be state on whether one or both
means should be used and if one overwrite the other.  A preference may
still be useful to indicate a preference when multiple keys for a given
role are available. Is key management a relevant usage for preference ?

I understand that Signing Time is being used to update the preferred
keys as one way to performed key roll over.    


3.1.  Preparing the MIME Entity for Signing, Enveloping, or Compressing

 A MIME entity can be a sub-
   part, sub-parts of a message, or the whole message with all its sub-
   parts. 

I am wondering if "a subpart, many subparts or ..." would not be
clearer.

I understand that "message" in the first paragraph is used as the MIME
message and in other words, the message is not designating the mail. I
am reading message as MIME multi-part message and the MIME entities as a
subset of MIME headers and parts of MIME multi-part message. Similarly
MIME body would be the MIME multi-part message.  Is that correct ? I
believe the terminology paragraph could be clarified. 


 It is
   RECOMMENDED that a distinction be made between the location of the
   header.
 
I believe the purpose is to make a distinction between "protected" and
'unprotected' to the end user. I would thus keep this distinction even
though this translates into 'inner' / 'outer'.


3.3.  Creating an Enveloped-Only Message
 

A sample message would be:

   Content-Type: application/pkcs7-mime; name=smime.p7m;
           smime-type=enveloped-data

Shouldn't we use an OID instead of data for the example ?



3.4.  Creating an Authenticated Enveloped-Only Message

I believe the word "proof" is missing. 

 It is important to note that
   sending authenticated enveloped messages does not provide for
   origination when using S/MIME. 

Maybe we should specify that this is especially true when multiple
recipients are involved.

3.5.3.  Signing Using the multipart/signed Format

 The first part contains
   the MIME entity that is signed; the second part contains the
   "detached signature" CMS SignedData object in which the
   encapContentInfo eContent field is absent.

I believe it would be good to specify parts are ordered as this is not
always the case of parts. What is unclear to me is why the second part
is separated by a boundary usually used to separate parts. It seems
boundary can also be used as boundary inside a part which seems to make
part parsing harder. 



3.5.3.2.  Creating a multipart/signed Message

    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)


Should we have any recommendations on the hash algorithm to be used by
sender / receivers ? Is that possible to deprecate MD5, SHA-1 and
SHA-224 for senders ?

 
3.7.  Multiple Operations

Would it be recommended to have signed clear text than encrypted and
then signed encrypted  ? This seems to address all security concerns. 

3.9.  Registration Requests

Should we mention DANE rfc8162 as a way to register you public key ?

4.  Certificate Processing

EdDSA Signatures recommendations for curve25519 and curve448 seems to be
missing in the key pair generating , signature section. Are there any
reasons not to consider these curves ?

May be useful to have the following references:
[1] https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/  
[2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/

6.  Security Considerations

I am wondering if any considerations should be provided for data at
rest.  Does the email needs to be archived encrypted or not and whether
S/MIME can be used to store encrypted content. I believe that email
should not be stored encrypted and as such S/MIME is only intended to
protect mails in transit....  but I might be wrong.   

As a general comment I would have like a table that summarizes or
explicitly mention what crypto is recommended for encrypting / signing.
RSA is being discussed, but ECDSA EdDSA, ECDH, hash... are not. I
believe such tables should be updated regularly to deprecate  and
introduce new algorithms while leaving S/MIME unchanged. 
  
There are a lot of double space in the text.