Subject: 3850bis and 3851bis: proposed changes to cryptographic key sizes

From: Tim Polk <[email-masked]>
Date: Mon, 5 Jan 2009 16:24:56 -0500

Folks,

3850bis and 3851bis are tentatively scheduled for discussion on this  
week's IESG telechat (Thursday, January 8).  Those that read the IETF  
Last Call email or subscribe to the saag or cfrg mailing lists  
already know that I have concerns about the cryptographic key sizes  
specified in these documents (especially the mandate to support 512  
bit RSA in 3850bis).  While the IETF Last Call was largely silent on  
this issue, the saag and cfrg feedback indicate that the mandatory to  
implements should not include cryptography weaker that 1024 bit RSA,  
but that the interoperability concerns should be clearly specified.

I have had some private discussions with one of the authors (Sean),  
and we have collaborated on some language that would reflect that  
discussion. However, I understand that this was a sensitive and  
somewhat controversial topic on the working group list.  I would like  
the working group to review the proposed RFC Editor Notes for 3850bis  
and 3851bis, and confirm that these changes are acceptable given the  
feedback received from the wider Internet community.  That is, please  
consider whether the proposed new text addresses the working group's  
concerns given that the minimum strength of the mandatory to  
implements need to be raised.

Early feedback would be appreciated!

Thanks,

Tim Polk

--------------------

RFC Editor Note for draft-ietf-smime-3850bis

(1) In Section 4.2., Certificate and CRL Signing Algorithms and Key  
Sizes, please make the following substitution:

OLD:

The following are the RSA key size requirements for S/MIME receiving  
agents during certificate and CRL signature verification:

       0 <  key size <   512 : MAY  (see Section 6)
     512 <= key size <= 4096 : MUST (see Section 6)
    4096 <  key size         : MAY  (see Section 6)

The following are the DSA key size requirements for S/MIME receiving  
agents during certificate and CRL signature verification:

     512  <= key size <= 1023 : MAY      (see Section 6)
     1024  = key size         : SHOULD-  (see Section 6)

NEW:

The following are the RSA key size requirements for S/MIME receiving  
agents during certificate and CRL signature verification:

            key size <= 1023 : MAY  (see Section 6)
    1024 <= key size <= 4096 : MUST (see Section 6)
    4096 <  key size         : MAY  (see Section 6)

The following are the DSA key size requirements for S/MIME receiving  
agents during certificate and CRL signature verification:

             key size <= 1023 : MAY      (see Section 6)
     1024  = key size         : SHOULD-  (see Section 6)

(2) In Section 6 Security Considerations, please make the following  
substitution:

OLD:

The 4096-bit RSA key size requirement for certificate and CRL  
verification is larger than the 2048-bit RSA key sizes for message  
signature generation/verification or message encryption/decryption in  
[SMIME-MSG] because many Root CAs included in certificate stores have  
already issued Root certificates with 4096-bit key.  The standard  
that defines comparable key sizes for DSA is not yet available.  In  
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes  
between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only  
allowed DSA key sizes of 1024 bits.  A revision to support larger key  
sizes is being developed, and once it is available, implementors  
ought to support DSA key sizes comparable to the RSA key sizes  
recommended in this specification.

Today, 512-bit RSA and DSA keys are considered by many experts to be  
cryptographically insecure.

NEW:

The 4096-bit RSA key size requirement for certificate and CRL  
verification is larger than the 2048-bit RSA key sizes for message  
signature generation/verification or message encryption/decryption in  
[SMIME-MSG] because many Root CAs included in certificate stores have  
already issued Root certificates with 4096-bit key.  The standard  
that defines comparable key sizes for DSA is not yet available.  In  
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes  
between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only  
allowed DSA key sizes of 1024 bits.  A revision to support larger key  
sizes is being developed, and once it is available, implementors  
ought to support DSA key sizes comparable to the RSA key sizes  
recommended in this specification.   Further, 4096-bit keys are  
normally only used by Root certificates and not by subordinate CA  
certificates; thereby, lengthening the Root CA certificate’s validity  
period.

RSA and DSA keys of less than 1024 bits are now considered by many  
experts to be cryptographically insecure (due to advances in  
computing power), and should no longer be used to sign certificates  
or CRLs.  Such keys were previously considered secure, so processing  
previously received signed and encrypted mail may require processing  
certificates or CRLs signed with weak keys.  Implementations that  
wish to support previous versions of S/MIME or process old messages  
need to consider the security risks that result from accepting  
certificates and CRLs with smaller key sizes (e.g., spoofed  
certificates) versus the costs of denial of service.  If an  
implementation supports verification of certificates or CRLs  
generated with RSA and DSA keys of less than 1024 bits, it MUST warn  
the user.  Implementers should consider providing a stronger warning  
for weak signatures on certificates and CRLs associated with newly  
received messages than the one provided for certificates and CRLs  
associated with previously stored messages.  Server implementations  
(e.g., secure mail list servers) where user warnings are not  
appropriate SHOULD reject messages with weak cryptography.

--- end of RFC Editor Note for draft-ietf-smime-3850bis ---

RFC Editor Note for draft-ietf-smime-3851bis

(1) In Section 4.2 Signature Generation, please make the following  
substitution:

From:

The following are the requirements for an S/MIME agent generated RSA  
signatures:

     512 <= key size <  1024 : MAY     (see Security Considerations)
    1024 <= key size <= 2048 : SHOULD  (see Security Considerations)
    2048 <  key size         : MAY     (see Security Considerations)

The following are the requirements for an S/MIME agent generated DSA  
signatures:

     512 <= key size <= 1023 : MAY     (see Security Considerations)
    1024  = key size         : SHOULD- (see Security Considerations)

To:

The following are the requirements for an S/MIME agent generated RSA  
signatures:

            key size <= 1023 : MAY     (see Security Considerations)
    1024 <= key size <= 2048 : SHOULD  (see Security Considerations)
    2048 <  key size         : MAY     (see Security Considerations)

The following are the requirements for an S/MIME agent generated DSA  
signatures:

            key size <= 1023 : MAY     (see Security Considerations)
    1024  = key size         : SHOULD- (see Security Considerations)

(2) In Section 4.3 Signature Verification, please make the following  
substitution:

OLD:

The following are the requirements for S/MIME receiving agents during  
signature verification of RSA signatures:

     512 <= key size <= 2048 : MUST    (see Security Considerations)
    2048 <  key size         : MAY     (see Security Considerations)

The following are the requirements for S/MIME receiving agents during  
signature verification of DSA signatures:

     512 <= key size <= 1023 : MAY     (see Security Considerations)
    1024  = key size         : SHOULD- (see Security Considerations)

NEW:

The following are the requirements for S/MIME receiving agents during  
signature verification of RSA signatures:

            key size <= 1023 : MAY     (see Security Considerations)
    1024 <= key size <= 2048 : MUST    (see Security Considerations)
    2048 <  key size         : MAY     (see Security Considerations)

The following are the requirements for S/MIME receiving agents during  
signature verification of DSA signatures:

            key size <= 1023 : MAY     (see Security Considerations)
    1024  = key size         : SHOULD- (see Security Considerations)

(3) In Section 6 Security Considerations, please make the following  
substitution:

OLD:

Today, 512-bit RSA and DSA keys are considered by many experts to be  
cryptographically insecure.

Using weak cryptography in S/MIME offers little actual security over  
sending plaintext.  However, other features of S/MIME, such as the  
specification of AES and the ability to announce stronger  
cryptographic capabilities to parties with whom you communicate,  
allow senders to create messages that use strong encryption.  Using  
weak cryptography is never recommended unless the only alternative is  
no cryptography.  When feasible, sending and receiving agents SHOULD  
inform senders and recipients of the relative cryptographic strength  
of messages.

NEW:

Using weak cryptography in S/MIME offers little actual security over  
sending plaintext.  However, other features of S/MIME, such as the  
specification of AES and the ability to announce stronger  
cryptographic capabilities to parties with whom you communicate,  
allow senders to create messages that use strong encryption.  Using  
weak cryptography is never recommended unless the only alternative is  
no cryptography.

RSA and DSA keys of less than 1024 bits are now considered by many  
experts to be cryptographically insecure (due to advances in  
computing power), and should no longer be used to protect messages.   
Such keys were previously considered secure, so processing previously  
received signed and encrypted mail will often result in the use of  
weak keys. Implementations that wish to support previous versions of  
S/MIME or process old messages need to consider the security risks  
that result from smaller key sizes (e.g., spoofed messages) versus  
the costs of denial of service.  If an implementation supports  
verification of digital signatures generated with RSA and DSA keys of  
less than 1024 bits, it MUST warn the user.  Implementers should  
consider providing different warnings for newly received messages and  
previously stored messages.  Server implementations (e.g., secure  
mail list servers) where user warnings are not appropriate SHOULD  
reject messages with weak signatures.

--- end of RFC Editor Note for draft-ietf-smime-3851bis ---

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Jan 2009 14:05:24 -0800

At 4:24 PM -0500 1/5/09, Tim Polk wrote:
>I have had some private discussions with one of the authors (Sean), and we have collaborated on some language that would reflect that discussion. However, I understand that this was a sensitive and somewhat controversial topic on the working group list.  I would like the working group to review the proposed RFC Editor Notes for 3850bis and 3851bis, and confirm that these changes are acceptable given the feedback received from the wider Internet community.  That is, please consider whether the proposed new text addresses the working group's concerns given that the minimum strength of the mandatory to implements need to be raised.

The new ranges and new text work for me.

What does *not* work for me is this being done as an RFC Editor note. It should be done instead as a new draft before IESG consideration so the whole IETF community can see the changes. The IETF is supposed to be working on transparency, and keeping these out of the Internet Draft hurts that effort.

---

From: Tim Polk <[email-masked]>
Date: Mon, 05 Jan 2009 22:14:22 -0500

On Jan 5, 2009, at 5:05 PM, Paul Hoffman wrote:

>> I have had some private discussions with one of the authors  
>> (Sean), and we have collaborated on some language that would  
>> reflect that discussion. However, I understand that this was a  
>> sensitive and somewhat controversial topic on the working group  
>> list.  I would like the working group to review the proposed RFC  
>> Editor Notes for 3850bis and 3851bis, and confirm that these  
>> changes are acceptable given the feedback received from the wider  
>> Internet community.  That is, please consider whether the proposed  
>> new text addresses the working group's concerns given that the  
>> minimum strength of the mandatory to implements need to be raised.
>
> What does *not* work for me is this being done as an RFC Editor  
> note. It should be done instead as a new draft before IESG  
> consideration so the whole IETF community can see the changes. The  
> IETF is supposed to be working on transparency, and keeping these  
> out of the Internet Draft hurts that effort.

I have to agree, these changes are too substantial to be buried in an  
RFC Editor Note while it sits in queue.  It is a nice format to frame  
the discussion, though.  If the working group is happy, I will ask  
the editors for new drafts before I request an approval announcement.