Subject: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 13 Apr 2018 14:21:22 -0700

The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
   Message Specification'
  <draft-ietf-lamps-rfc5751-bis-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-04-27. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document defines Secure/Multipurpose Internet Mail Extensions
   (S/MIME) version 4.0.  S/MIME provides a consistent way to send and
   receive secure MIME data.  Digital signatures provide authentication,
   message integrity, and non-repudiation with proof of origin.
   Encryption provides data confidentiality.  Compression can be used to
   reduce data size.  This document obsoletes RFC 5751.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Tim Hollebeek <[email-masked]>
Date: Sun, 15 Apr 2018 15:32:21 +0000

I just read the whole draft and have the following comments.  Overall, the
draft seems to be in excellent shape.

I apologize if any of these were discussed earlier in the process, before I
started following this draft.  More than happy to create a pull request with
the changes once I get some feedback on these.

Section 2.1:

Is it worth adding "SHOULD support SHA-3" ?

Section 2.2:

"NIST is unable to provide the seeds that were
   used to create their standardized curves, this means that there is a
   section of the community which believes that there might be a back
   door to these curves."

This is a comma splice; recommend changing the comma to semi-colon.

"there is only a requirement for curve in the sending agent list"

I think "only a requirement for ONE curve in the sending agent list" was
meant.

Section 2.7.2. "All algorithms that use 112-bit keys are considered by many
to be weak encryption."

Is the LENGTH of the key, or the STRENGTH of the key intended?

If the former, are there other examples of 112-bit keys other than two key
3DES (~80 bits of strength)?
If not, why not say two key 3DES to be explicit?

If the latter, what's the rationale for considering 112 bits of strength
weak for symmetric algorithms in a standard where RSA-2048 is considered
strong?

I don't find "considered by many" to be a useful statement.  After all, the
world is considered by many to be flat.

-Tim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Friday, April 13, 2018 5:21 PM
> To: IETF-Announce <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt>
> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message
> Specification) to Proposed Standard
> 
> 
sent
> to [email-masked] instead. In either case, please retain the beginning of
the
> Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Apr 2018 14:45:50 -0700

> From: Tim Hollebeek <[email-masked]>
> Sent: Sunday, April 15, 2018 8:32 AM
> To: [email-masked]; IETF-Announce <[email-masked]>
> Subject: RE: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt>
> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
> Message Specification) to Proposed Standard
> 

At the time this document cleared WGLC the answer was definitely no.  For
those people who believe in having consistency in all of the hash algorithms
the answer would still be no as there are no SHA-3 signature algorithms that
are currently either MUST or SHOULDs.  The answer would be different if
Ed448 was in that list.

I think that this means the answer is still no.

> I think "only a requirement for ONE curve in the sending agent list" was

Yes this is what should have been there.

> world is considered by many to be flat.

This should have been caught and updated when the security considerations
text was updated to address the same problem.

I have modified my copy to read

                Algorithms such as RC2 are considered to be weak encryption
algorithms.
                Algorithms such as TripleDES are not state of the art and
are considered to be weaker algorithms than AES.
                A sending agent that is controlled by a human SHOULD
                allow a human sender to determine the risks of sending data
using a
                weaker encryption algorithm before sending the data, and
possibly allow
                the human to use a stronger encryption algorithm such as AES
GCM or AES CBC even if there is a possibility 
	  that the recipient will not be able to process that algorithm.

Jim

---

From: Sean Turner <[email-masked]>
Date: Wed, 18 Apr 2018 16:30:30 -0400

> On Apr 15, 2018, at 17:45, Jim Schaad <[email-masked]> wrote:

+1

>> world is considered by many to be flat.

:). Yeah not my best weasel words.

> 	  that the recipient will not be able to process that algorithm.

lgtm