Subject: [Spasm] Change of Algorithms: Signature Algorithms Take 2

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Aug 2016 14:54:04 -0700

This message looks at Signature Algorithms.  Please restrict your
discussions to this set of algorithms, I will be sending out messages on
other algorithms over time.

Current Document for S/MIME 3.1

MUST:   RSA w/ SHA-256

SHOULD+:  DSA w/ SHA-256, RSASSA-PSS w/ SHA-256

SHOULD-:  RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5

Historic:

Key Sizes:

RSA and DSA - sign

SHOULD NOT            Key size <= 1023

SHOULD      1024 <= key size <= 2048

MAY            2048 < key size   

RSA and DSA - Verify

MAY                key size <= 1023

MUST      1024 <= key size <= 2048

MAY        2048 < key size

RSA - Certificate Verify

MAY             key size <= 1023

MUST  1024 <= key size <= 4096

MAY      4096  < key size

DSA - Certificate Verify

MAY             key size <= 1023

MUST    1024 <= key size <= 3072

Proposed for S/MIME 3.5

MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519

MUST-: RSA w/ SHA-256

SHOULD+:

SHOULD:  RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256512, EdDSA448

SHOULD-: DSA w/ SHA-256

Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ SHA-256

Key Sizes:

RSA and DSA - sign

SHOULD NOT            Key size <= 2048 2047

SHOULD      2048 <= key size <= 4096

MAY             4096 < key size   

RSA and DSA - Verify

Historic MAY                key size <= 2048 2047

MUST      2048 <= key size <= 4096

MAY        4096 < key size

RSA - Certificate Verify

Historic MAY             key size <= 2048 2047

MUST  2048 <= key size <= 4096

MAY      4096  < key size

DSA - Certificate Verify

Historic MAY             key size <= 1023

Historic MUST   1024 <= key size <= 3072

Questions:

1.      Should DSA be dropped to historic for messages and just left as
SHOULD- for certificates, I don't know how many DSA certificates actually
exist.

Take 2 state: I have removed all DSA from the current set of algorithms for
both messages and certificates.  This is now historic only

2.      I have changed to lower limits on RSA but not DSA for certificate
verification - should it be changed as well?  Again I don't know how many
DSA certificates exist.

Take 2 state: I have removed DSA certificates to historic so the question is
moot.

3.      I don't think that any statements for ECDSA on key size need to be
made separately from the algorithm support list.  Does anybody disagree?

Take 2 state:  Nobody said anything to the contrary.  So no plans to make a
key size section for ECDSA algorithms.

4.      NEW: SPT suggested that we should not be making any statements on
doing anything with 512 hash values.  (Although with tons of standard snark
:)).   My reasoning for including this was less to do with the fact that I
thought the 512-bit hash functions were more efficient on 64-bit hardware (a
statement that I cannot find support for with a quick web search for SHA-2)
and therefore it made sense from a throughput point of view.   I don't think
we need the for security and if they are not more efficient I would be in
favor not making them SHOULDs

5.      NEW:  Blake has complained about the number of MUST algorithms that
comes out from this list.  There are effectively 4 in the list above, as
opposed to the 1 that is in the current set of documents.  We cannot kill
the current MUST so it has to stay.  However, all of the new MUSTs could be
downgraded from MUST to SHOULD without out any problems.  The only issue is
that one of them needs to be a MUST so that we have a true MUST not just a
MUST- algorithm.  Looking at the list my breakdown would be:

*        RSA-PSS - Given that it has been slow on update the only reason to
have it be a MUST is that most people are probably going to have RSA keys
today.  There are some arguments that say RSA-PSS is no better than RSA-v1.5
when doing real-world analysis.  I don't know that I agree with this as I
have problems with arguments by analogy.   This could easily be a SHOULD
instead of a MUST

*        ECDSA - This is the world of NIST requirements today.  I think this
justifies it being a MUST

*        EdDSA - This is the world of NOT MIST requirements today.  I think
this justifies it being a MUST

Jim

---

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Aug 2016 18:49:22 -0400

Jim Schaad <[email-masked]> wrote:
    > discussions to this set of algorithms, I will be sending out messages
    > on other algorithms over time.

    > SHOULD+: DSA w/ SHA-256,

DSA has been limited to 1024 keys.
I think that this limit was removed, but I'd like to know what you intended
here?  I guess I also don't understand the 3.1/3.5 distinction. That's my
ignorance.

I see that you have been trying to capture a key difference between
encryption at rest (emails on disk) from IPsec/TLS.  We clearly need
to be able to look at email that was encrypted years (decades..) ago.
I think that the presentation of this distinction might need more clarity.

    > SHOULD- for certificates, I don't know how many DSA certificates
    > actually exist.

By "DSA certificates", do you mean end-users here?
For awhile, DSA was considered "more secure" by many EU based open source
crypto packages. (Not something I agreed with)
I don't know how many of those keys were used to create S/MIME messages.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Aug 2016 16:08:04 -0700

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: Sunday, August 07, 2016 3:49 PM
> To: 'SPASM' <[email-masked]>
> Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2
> 
> 
> I think that this limit was removed, but I'd like to know what you
intended here?
> I guess I also don't understand the 3.1/3.5 distinction. That's my
ignorance.

Yes, this limit was removed.  NIST defined a DSA key size for use with the
SHA-2 algorithms.

> I see that you have been trying to capture a key difference between
encryption
> at rest (emails on disk) from IPsec/TLS.  We clearly need to be able to
look at
> email that was encrypted years (decades..) ago.

I think you need to be looking at the document rather than these mails to
get this distinction.  S/MIME 3.1 was published as an RFC in 2009.  We are
in the process of doing an update of these RFCs and thus we are looking at
the difference between what was said then (3.1) and what we want to say in
the new document (3.5).

Old email is covered by the category "Historic".

> crypto packages. (Not something I agreed with) I don't know how many of
those
> keys were used to create S/MIME messages.

No, we are looking at DSA certificates throughout the entire certificate
chain.  When I say certificates, I am talking about certificates and not
email.  This is why the sentence draws a distinction between certificates
and messages.

Jim

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Aug 2016 10:39:12 -0400

I would like to see ECDSA P-384 w/ SHA-384 on the SHOULD list.

Russ

On Aug 7, 2016, at 5:54 PM, Jim Schaad <[email-masked]> wrote:

> This message looks at Signature Algorithms.  Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithms over time.
>  
> 1.      Should DSA be dropped to historic for messages and just left as SHOULD- for certificates, I don't know how many DSA certificates actually exist.
> 
> Take 2 state: I have removed all DSA from the current set of algorithms for both messages and certificates.  This is now historic only
>  
> 2.      I have changed to lower limits on RSA but not DSA for certificate verification - should it be changed as well?  Again I don't know how many DSA certificates exist.
> 
> Take 2 state: I have removed DSA certificates to historic so the question is moot.
>  
> 3.      I don't think that any statements for ECDSA on key size need to be made separately from the algorithm support list.  Does anybody disagree?
> 
> Take 2 state:  Nobody said anything to the contrary.  So no plans to make a key size section for ECDSA algorithms.
>  
> 4.      NEW: SPT suggested that we should not be making any statements on doing anything with 512 hash values.  (Although with tons of standard snark J).   My reasoning for including this was less to do with the fact that I thought the 512-bit hash functions were more efficient on 64-bit hardware (a statement that I cannot find support for with a quick web search for SHA-2) and therefore it made sense from a throughput point of view.   I don’t think we need the for security and if they are not more efficient I would be in favor not making them SHOULDs
>  
> 5.      NEW:  Blake has complained about the number of MUST algorithms that comes out from this list.  There are effectively 4 in the list above, as opposed to the 1 that is in the current set of documents.  We cannot kill the current MUST so it has to stay.  However, all of the new MUSTs could be downgraded from MUST to SHOULD without out any problems.  The only issue is that one of them needs to be a MUST so that we have a true MUST not just a MUST- algorithm.  Looking at the list my breakdown would be:
>  
> ·        RSA-PSS – Given that it has been slow on update the only reason to have it be a MUST is that most people are probably going to have RSA keys today.  There are some arguments that say RSA-PSS is no better than RSA-v1.5 when doing real-world analysis.  I don’t know that I agree with this as I have problems with arguments by analogy.   This could easily be a SHOULD instead of a MUST
> ·        ECDSA – This is the world of NIST requirements today.  I think this justifies it being a MUST
> ·        EdDSA – This is the world of NOT MIST requirements today.  I think this justifies it being a MUST
>  
> Jim
>  
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Aug 2016 14:43:52 +0000

> I would like to see ECDSA P-384 w/ SHA-384 on the SHOULD list.

I'd rather see 256 and 512 only.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Aug 2016 19:59:52 -0700

It seems to me that the same argument you made on 192 would apply here as
well.

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, August 08, 2016 7:39 AM
To: Jim Schaad <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2

Russ

On Aug 7, 2016, at 5:54 PM, Jim Schaad <[email-masked]
<mailto:[email-masked]> > wrote:

MUST:   RSA w/ SHA-256

Historic:

Key Sizes:

RSA and DSA - sign

MAY            2048 < key size  

RSA and DSA - Verify

MAY                key size <= 1023

MAY        2048 < key size

RSA - Certificate Verify

MAY             key size <= 1023

MAY      4096  < key size

DSA - Certificate Verify

MAY             key size <= 1023

 

Proposed for S/MIME 3.5

MUST-: RSA w/ SHA-256

SHOULD+:

SHOULD-: DSA w/ SHA-256

Key Sizes:

RSA and DSA - sign

MAY             4096 < key size  

RSA and DSA - Verify

MAY        4096 < key size

RSA - Certificate Verify

MAY      4096  < key size

DSA - Certificate Verify

 

Questions:

Jim

_______________________________________________
Spasm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/spasm>
https://www.ietf.org/mailman/listinfo/spasm