Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07
Jim Schaad <ietf@augustcellars.com> Wed, 02 May 2018 18:56 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC412DA11; Wed, 2 May 2018 11:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeYRK19MCF0w; Wed, 2 May 2018 11:56:24 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AC512DA1A; Wed, 2 May 2018 11:56:14 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 11:52:38 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Daniel Migault' <daniel.migault@ericsson.com>, secdir@ietf.org
CC: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org
References: <152485706488.6011.12980717250490137013@ietfa.amsl.com>
In-Reply-To: <152485706488.6011.12980717250490137013@ietfa.amsl.com>
Date: Wed, 02 May 2018 11:55:08 -0700
Message-ID: <052201d3e247$19431b20$4bc95160$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGKQIh8Fnl9XoAAnVF7fk1Lowwoi6SoQLLQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/HJSnGyJo6pU5FUnMbFdidWjAqnA>
Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 18:56:27 -0000
I have published a -08 with these changes. > -----Original Message----- > From: Daniel Migault <daniel.migault@ericsson.com> > Sent: Friday, April 27, 2018 12:24 PM > To: secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 > > 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. > Done > > 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. Interesting observation. In all of the work that I have ever done I have always referred to the difference between PKCS #v1.5 signature, PKCS #v1.5 encryption, OAEP, PSS and KEM and different encryption algorithms rather than just saying that the formats are different. Saying format would make a degree of sense between the two different 1.5 algorithms, however if you compare v1.5 signature and PSS then more than just the format of the data can be thought of as being involved. I don't think that this makes sense. > > > 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. This probably falls under the category of "I don't care", the object is to make sending agents do the right thing. However, I have added test about security strengths for reciepents. > > 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. I don't think this necessary for the other content types. The problem is that many people think that AED algorithms automatically provide authentication. There are some situations where this is true, but they are not met when doing S/MIME. > > 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. I have added the following sentence to the first paragraph These attributes can be required for processing of message (i.e. Message Digest), information the signer supplied (i.e. SMIME Capabilities) that should be processed, or attributes which are not relevant in the current situation (i.e. mlExpansionList <xref target="RFC2634"/> for mail viewers). I don't think a forward reference to 2.7 would be useful at this point. > > 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. Replaced message originator with signer. > > 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 ? I don't really want to try and quantify what long means because for different clients it can mean different things. In some considerations one could consider listing 3 encryption algorithms to be long while in other situations it might be 30 encryption algorithms that is too long. If I want to send you a message and need to be sure that there is a common enabled language then 30 encryption algorrithms is better. On the other hand trying to figure out a common algorithm for a message going to 100 recipients where each has a different set of algorithms and in a different ranking order and come up with the best one means even 3 can feel really long. The problem is not byte count as even 30 items at 10 bytes apiece is only 300 bytes which relative to the rest of a signed MIME message is pretty small. The problem is the question of how to make a decision and the parameters are different based on how that algorithm is implemented. While the information can be cached, I don't know that it can be assured to be cached. Additionally this might put a greater burden on the sender as it would need to know if the current configuration has been sent to a recipient. It is easier to just always send the list. However I cannot see that there is any requirements on the document on having sending the attribute just on receiving it. > > 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. I don't know that adding a table is going to be useful. Much of this information is not really designed to be put into a table unless you are going to footnote the heck out of it which kind of defeats the process. This information is scattered through out the document, but it tries to be in the right place for a specific field. > > 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. While there is some similarity between key usage and this attribute, the attribute is more general and allows for things which are not necessarily mentioned here. As an example, one could send different certificates with different algorithms or key sizes and express a preference on which certificate to use. It may be that the names between the signing certificate and encryption key certificate are not the same, in that case which should be used. I think that this is covered in the introduction and a reference to key usage is not really helpful. > > > 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 don't see this as being 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. There is no requirement that message be multi-part, it could be a single-part message such as text/plain. However that is generally correct. How do you believe that the text can be clarified. Specific text would be helpful. > > > 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'. The problem of how to do this has been a topic of many discussions without ever getting to a conclusion. One of the problems is that protected can mean some different things depending on how you protect the headers. For example, one could have a multipart/mixed message with two sections each of which consists of an encrypted message. If each of those has different protected headers in them then, while the difference between inner and outer makes sense as that is part of the tree structure, which set of protected headers now needs to be dealt with. > > > 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 ? I don't know what you are trying to ask here. > > > > 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. done > > 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. The order is part of the definition of multipart/signed. In the definition of multipart/*, the rules require that the boundary string not exist within any of the different child body parts. This means that it can be used to uniquely distinguish the boundaries. > > > > 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 ? The recommendations on which algorithms to use is part of the signature algorithm recommendations. This is a different table and removing items would be potentially harmful. > > > 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. There are a large number of security concerns that have been uncovered with each of the different orders of operations. Part of the question is going to be what concern are you trying to address and what are the informal rules about this. I don't think at this point we can really give an order, however RFC 2634 does have some guidance. > > 3.9. Registration Requests > > Should we mention DANE rfc8162 as a way to register you public key ? I don't think so, we don’t ever talk about how to find keys in the document. > > 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/ Should have had [1] as a reference, the reference was there but not the pointer to it. The second would be referenced in rfc5750-bis not here. > > 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. I believe you to be wrong. There are no problems w/ using S/MIME as a data at rest protection scheme. The question of storing messages as encrypted or not is something that different clients have dealt with in different ways. The client I use leaves things encrypted which I consider to be the correct answer. > > 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. To do this would require that the algorithms be maintained in a separate document. As above, I don't think a separate table adds to clarity as it duplicates information and would be hard to write. > > There are a lot of double space in the text. > Jim
- [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