Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03

From: Russ Housley <[email-masked]>
Date: Thu, 9 Mar 2017 16:01:56 -0500

I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03.  I have divided my comments into MAJOR and MINOR.

MAJOR

Do we need to define a way for smimeCapabilities to state support for AuthEnveloped?  I’m trying to avoid interoperability failures.

Section 2.1: I see no need to include the MUST for SHA-512 here since none of the algorithms in Section 2.2 use it.

Section 2.7.1.2: I worry about backward compatibility here.  This requires a capability that has never been used in S/MIME before, so it seems premature to use AES-GCM when the capabilities of the recipient are unknown.  Instead, I would argue that AES-256 CBC offers implementers so time to deploy authenticated encryption.  This looks like a fine thing for S/MIME 4.1 in a couple of years.

Section 5.1: The S/MIME WG is closed.  Would it be better to change the contact to the IESG?

MINOR

Section 1.2, definition of Data Integrity Service: s/insuring/ensuring/

Section 1.2, definition of Data Confidentiality: s/authorize/authorized/

Section 1.7: there are two missing “)” characters

Section 2.2: for clarity, please say, "MUST- support RSA PKCS#1 v1.5 Signature with SHA-256” for sending and receiving.

Section 2.3: for clarity, please say, "MUST- support RSA  PKCS#1 v1.5 Encryption”.

Section 2.7: I think we need to continue to support both AES-128 CBC and AES-256 CBC as MUST-.  (See my comment on Section 2.7.1.2.)

Section 3.2.2: s/authEnvelopedData/authEnveloped-data/  (All of the other names end in “-data”.)

Section 3.4: s/confidentiality and integrity/confidentiality and data integrity/

Section 3.4: s/smime-type=authEnvelopedData/smime-type=authEnveloped-data/ (See my comment on Section 3.2.2.)

Section 4.1: s/RSA signature algorithm/RSA PKCS#1 v1.5 Signature algorithm/

Section 4.2: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature and RSASSA-PSS signatures/

Section 4.3: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature and RSASSA-PSS signatures/

Section 4.4: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption and RSA-OAEP algorithms/

Section 4.5: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption and RSA-OAEP algorithms/

Section 5.3: s/authEnvelopedData/authEnveloped-data/ (See my comment on Section 3.2.2.)

Section 6: s/shared secret when doing encryption/shared secret for encryption/

Section 6: s/New key key agreement algorithms/New key agreement algorithms/

Russ

---

From: Jim Schaad <[email-masked]>
Date: Thu, 9 Mar 2017 23:36:02 -0800

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, March 9, 2017 1:02 PM
> To: SPASM <[email-masked]>
> Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03
> 
> I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03.  I
> have divided my comments into MAJOR and MINOR.
> 
> 
> MAJOR
> 
> Do we need to define a way for smimeCapabilities to state support for
> AuthEnveloped?  I’m trying to avoid interoperability failures.

We have that.  If you support an AEAD algorithm then you must support AuthEnveloped by definition.

> of the algorithms in Section 2.2 use it.

This is to get a match for EdDSA w/ curve 25519.  That uses SHA-512 internally so that the correct match would be to use SHA-512 for the external as well.

> 
> Section 2.7.1.2: I worry about backward compatibility here.  This requires a
> capability that has never been used in S/MIME before, so it seems premature
> to use AES-GCM when the capabilities of the recipient are unknown.  Instead,
> I would argue that AES-256 CBC offers implementers so time to deploy
> authenticated encryption.  This looks like a fine thing for S/MIME 4.1 in a
> couple of years.

This has been the traditional wording over the last three versions of the document.  Only for 3851 was it clear that the algorithm existed as a possibility prior to the version being released.  The group has normally recommended using the best algorithm here but permitted to use of a different algorithm.  I think there is sufficient guidance in the text about why GCM was chosen and it allows for either it or AES-128 CBC to be used.

> Section 5.1: The S/MIME WG is closed.  Would it be better to change the

I thought about this and did not do it, but yes it makes sense.   I wonder how many people have used the contact, but as I am not on this alias I would not know. 

Jim

> Section 2.2: for clarity, please say, "MUST- support RSA PKCS#1 v1.5
> Signature with SHA-256” for sending and receiving.
> 
> Section 2.7: I think we need to continue to support both AES-128 CBC and
> AES-256 CBC as MUST-.  (See my comment on Section 2.7.1.2.)
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Mar 2017 09:48:59 -0500

> We have that.  If you support an AEAD algorithm then you must support AuthEnveloped by definition.

Sure.  I think the document needs to be explicit on this point.

> This is to get a match for EdDSA w/ curve 25519.  That uses SHA-512 internally so that the correct match would be to use SHA-512 for the external as well.

Okay.  This one is resolved.

> This has been the traditional wording over the last three versions of the document.  Only for 3851 was it clear that the algorithm existed as a possibility prior to the version being released.  The…

Since a new content type is involved, not just a new algorithm, I am advocating a slower transition.  I’d love to hear from others.  Am I being too conservative?

> I thought about this and did not do it, but yes it makes sense.   I wonder how many people have used the contact, but as I am not on this alias I would not know. 

Let’ make it the IESG.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Mar 2017 11:55:01 -0400

i want to confirm that version -04 resolves all of my comments, except one.  That one is being discussed on the thread that Jim started yesterday.

Russ

> On Mar 10, 2017, at 9:48 AM, Russ Housley <[email-masked]> wrote:
> 
>