[lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07
Daniel Migault <email@example.com> Fri, 27 April 2018 19:24 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E568312DA15; Fri, 27 Apr 2018 12:24:24 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Daniel Migault <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Date: Fri, 27 Apr 2018 12:24:24 -0700
Subject: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2018 19:24:31 -0000
Reviewer: Daniel Migault Review result: Has Nits 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. 22.214.171.124. 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:  https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/  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.
- [lamps] Secdir last call review of draft-ietf-lam… Daniel Migault
- Re: [lamps] Secdir last call review of draft-ietf… Jim Schaad
- Re: [lamps] Secdir last call review of draft-ietf… Daniel Migault