Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07

[Daniel Migault <[e-mail]>]

Hi Jim,

Thanks you for the clarifications. Please see my comments inline.

Yours,
Daniel

On Wed, May 2, 2018 at 2:55 PM, Jim Schaad <[e-mail]> wrote:

> I have published a -08 with these changes.
>
> > -----Original Message-----
> > From: Daniel Migault <[e-mail]>
> > Sent: Friday, April 27, 2018 12:24 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; draft-ietf-lamps-rfc5751-bis.a
> [e-mail]
> > 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.
>

This comment was just mentioned as  potential nits. I am fine with protocol
and understand the reasons. Thanks for the explanation. I cannot find where
I found the use of "format" and RFC8017 seems to use "scheme".


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

Thanks.


>
> >
> > 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.
>
> I agree. My comment was only to mention that 2.4.2 and 2.4.4 could use
similar formulation.

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

I think that helps the reading. Thank you.

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

>
> >
> > 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.
>
> I got it, but my point was that by having a mandatory to implement
cryptography document, would enable to have inter operable cryptographic
primitives that evolve over time. Such document will provide the necessary
overlaps. This is how we proceed with IKEv2 / IPsec... but S/MIME may have
different deployment considerations.   I see your last comment you do not
think that is useful. I am fine as long as I am sure you got my purpose..

>
> >
> > 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.
>
>
I agree with you point. However, I believe that a mandatory to implement
guidance section or document would be helpful to specify which crypto is
mandatory and the status of the other algorithms. Evolution of the crypto
may address another scope than the protocol description and might be
another document.   Again this is addressed by your last comment.

> >
> > 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.
>
> The response clarifies my question thanks.

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

I believe that replacing message by MIME message would clarify the
difference between the message of the email. Then clarifying that MIME
message is composed of MIME entities.

Here is what I would propose:

S/MIME is used to secure MIME entities. A MIME message is composed of a
MIME header and a MIME body, which both can be constituted of a single
part or of multiple parts. Any of these parts is designated as a MIME
message part.
A MIME entity can be a sub-
   part, sub-parts of a MIME message, or the whole Mime message with
all its sub-
   parts.  A MIME entity that is the whole MIME message includes only the
   MIME message headers and MIME body, and does not include the
RFC-822 <https://tools.ietf.org/html/rfc822>
   header.  Note that S/MIME can also be used to secure MIME entities
   used in applications other than Internet mail.  If protection of the
   RFC-822 <https://tools.ietf.org/html/rfc822> header is required,
the use of the message/rfc822 media type
   is explained later in this section.






>
> >
> >
> >  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.
>
> Thanks for the explanation. I agree.


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

I though of specifying an OID instead of using data, but I agree that data
is preferred.


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

Agree. Thanks for the clarification.

>
> >
> >
> >
> > 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.
>
> I am reading this as new implementations should still implement MD5. If
so, I believe an explanation might be useful.


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

Correct. Maybe it would be useful the section references ESS for further
recommendations. But I agree the reference has been mentioned earlier.

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

Agree ;-)

>
> >
> > 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.
>
> I see why... if there are no clear rules, it might be better to leave it
as it is. I agree.


> >
> > 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
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>