Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt

From: [email-masked]
Date: Mon, 29 Aug 2016 21:04:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF.

        Title           : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Message Specification 
        Authors         : Jim Schaad
                          Blake Ramsdell
                          Sean Turner
	Filename        : draft-ietf-lamps-rfc5751-bis-01.txt
	Pages           : 53
	Date            : 2016-08-29

Abstract:
   This document defines Secure/Multipurpose Internet Mail Extensions
   (S/MIME) version 3.5.  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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Aug 2016 00:29:18 -0400

I did a very quick skim of the -01 version.  Thanks.

I expected Section 2.3 to include ECDH and X25519.  If they are added, some related guidance will be needed in Sections 4.4 and 4.5.

Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH algorithms.  It used to contain some guidance about DSA.  Is there any reason to remove DSA guidance from 4.2 and 4.3?  I think we need to add guidance in Sections 4.2 and 4.3 for ECDSA and EdDSA.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 29 Aug 2016 21:29:09 -0700

This update has the algorithm updates with the following exceptions:

1.  The key management changes have not been done yet.
2.  The signature algorithms doesn't have P-384 listed in them.

The first is just a timing issue.
The second is because at this time the only person that I have seen arguing
for this is Russ.  I would like to see some additional support or some
additional reasoning to add this.  I am not sure that this does not fall
into the same category as the arguments about doing 192 bit AES, would
people really use 384 or just jump to 448 and 521?

The update to the certs draft has also been submitted with the same set of
changes and should be coming out shortly.

Jim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Monday, August 29, 2016 9:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt
> 
> 
> This draft is a work item of the Limited Additional Mechanisms for PKIX
and
> SMIME of the IETF.
> 
>         Title           : Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version
> 3.5 Message Specification
>         Authors         : Jim Schaad
>                           Blake Ramsdell
>                           Sean Turner
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Aug 2016 00:32:52 -0400

Jim:

Thanks for the updated draft.

> people really use 384 or just jump to 448 and 521?

I will point out that the Suite B community will use P-384.  I do not know if there are others.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Aug 2016 11:20:00 -0700

> From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Monday, August 29, 2016 9:29 PM
> To: SPASM <[email-masked]>
> Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt
> 
> I expected Section 2.3 to include ECDH and X25519.  If they are added,
some
> related guidance will be needed in Sections 4.4 and 4.5.

Our messages much have crossed where I said that this wasn't done for timing
issues.
I am not sure what type of guidance needs to be added to section 4.4. and
4.5 though, there is no concept of having different sized keys as the MUST
requirements in section 2.3 are going to require a specific key size.

> 
> Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH
> algorithms.  It used to contain some guidance about DSA.  Is there any
reason to
> remove DSA guidance from 4.2 and 4.3?  I think we need to add guidance in
> Sections 4.2 and 4.3 for ECDSA and EdDSA.

I am in the process of trying to remove all DSA guidance to section B.2 for
clarity.  It is just going to take a while to  go through section 4.1 and
clean that one up.  

As above since they section 4.2-4.5 are all dealing with key sizes, what
guidance do you think needs to be in there given that we are dealing with
fixed sized keys for ECDSA and EdDSA in requirements.
  It would make more sense to list specific curves as may in section 2.x

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Aug 2016 15:48:14 -0400

Jim:

>> I expected Section 2.3 to include ECDH and X25519.  If they are added,some

Yes, I think so.

> requirements in section 2.3 are going to require a specific key size.

For Section 4.4, I was thinking about something like …

   An S/MIME agent when establishing keys for content encryption using the
   ECDH MUST support P-256, and MAY support other curves as well.

For there CFRG curves, maybe we only say that X25519 MUST be supported
that X448 MAY be supported.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 30 Aug 2016 14:49:46 -0700

> Sent: Tuesday, August 30, 2016 12:48 PM
> To: Jim Schaad <[email-masked]>
> Cc: SPASM <[email-masked]>
> >> I expected Section 2.3 to include ECDH and X25519.  If they are
> >> added,some related guidance will be needed in Sections 4.4 and 4.5.
> >
> > Our messages much have crossed where I said that this wasn't done for
> > timing issues.
> 
> Yes, I think so.
> 
> > 4.5 though, there is no concept of having different sized keys as the
> > MUST requirements in section 2.3 are going to require a specific key
size.
> 
> For Section 4.4, I was thinking about something like .
> 
that
> X448 MAY be supported.

But why would that not be in section 2.X instead?  It is not like X25519
supports different key sizes which is what is currently documented in
section 4.

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Aug 2016 17:55:22 -0400

> supports different key sizes which is what is currently documented in

This seems to be the place that the document says you MAY do stronger things too.

Russ