Subject: Re: [Cfrg] Requesting guidance on key sizes for 3850bis and 3851bis

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Dec 2008 16:43:25 -0800

Peter,

I for one am being helped.  I have existing signed and encrypted mail in my
mailboxes that uses keys that are smaller than 1024 bit lengths.   Please
note that the text referred only to receiving agents and not to sending
agents.

jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Gutmann
> Sent: Wednesday, November 19, 2008 8:23 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Cfrg] Requesting guidance on key sizes for 3850bis and
> 3851bis
> 
> Tim Polk <[email-masked]> writes:
> 
> >Given the lack of response from the wider community, I would greatly
> >appreciate any input the CFRG can provide.
> 
> I would strongly support finally deprecating keys < 1024 bits, for two
> reasons.  Firstly, anyone using these is going to get dinged by
> security
> auditors if they see 512-bit keys used, and it'll cause problems with
> things
> like FIPS 140 certifications as well [0], which means that it's going
> to bite
> people at some point regardless of whether the specs (appear to) allow
> it.
> Secondly, it would finally provide a means of ending the pointless
> arguments
> over "we can keep on using 512-bit keys in perpetuity because there's
> nothing
> in the spec that says we can't" that vendors tend to use when customers
> ask
> why their product doesn't support certain security features.
> 
> (Just out of interest, who is actually being helped by a spec that
> still
>  allows 512-bit keys in 2009 and beyond?).
> 
> Peter.
> 
> [0] That's a generalisation, in practice it's the usual crapshoot, some
> labs
>     will allow < 1024-bit keys and some won't.  For my own code I've
> had one
>     lab pass 512-bit keys OK and another one say that any ability to
> use keys
>     of less than 1024 bits would mean it couldn't be evaluated.  In
> another,
>     more amusing case reported to me by someone else, they got one lab
> to OK
>     it at 512 bits, then a second lab required them to submit paperwork
>     showing that they blocked all keys of less than 1024 bits, and
> after they
>     did that the first lab complained that they were failing their
> tests on
>     512-bit keys.  In the end they just declared that their product
> didn't
>     support any keys less than 1024 bits and everything was OK.
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: David McGrew <[email-masked]>
Date: Thu, 4 Dec 2008 05:34:02 -0800

Hi Tim,

On Nov 19, 2008, at 4:06 PM, Tim Polk wrote:

> Folks,
>
> I requested IETF Last Call for two documents from the S/MIME working  
> group at the end of October.  In the Last Call messages, I asked for  
> community input on two issues regarding cryptographic key sizes.   
> The two week Last Call resulted in exactly one response, so I am  
> requesting further guidance from the cfrg.
>
> Here is the relevant excerpt from the Last Call for 'Secure/ 
> Multipurpose Internet Mail Extensions (S/MIME) Version 3.2  
> Certificate Handling', <draft-ietf-smime-3850bis-08.txt>
>
>> In particular, the IESG solicits comments on the cryptographic  
>> strength
>> requirements specified in section 4.3, Certificate and CRL Signing
>> Algorithm and Key Sizes, and the following statement from Section 6,
>> Security Considerations:
>>
>>   "Today, 512-bit RSA, DSA and DH keys are considered by many experts
>>   to be cryptographically insecure."

To make the above statement stronger, we could add the following:

Real-world, experimental factorizations of 512-bit RSA [1], and 664- 
bit RSA [2], have been accomplished.  The resources used in these  
efforts were fewer than 100 CPU-years for a modern CPU.   This is  
direct evidence that 664-bit RSA, DSA, and DH can be undermined.

[1] S. Cavallar, W.M. Lioen, H.J.J. te Riele, B. Dodson, A.K. Lenstra,
P.L. Montgomery, B. Murphy et al. "Factorization of a 512--bit RSA  
modulus", February, 2000.
http://www.cwi.nl/ftp/CWIreports/MAS/MAS-R0007.ps.Z

[2]  F. Bahr, M. Boehm, J. Franke, T. Kleinjung, "We have factored  
RSA200", email, May 2005.
http://www.crypto-world.com/announcements/rsa200.txt

>>
>>
>> These sections require S/MIME recieving agents to support RSA key  
>> lengths
>> between 512 and 1024 bits, and permit support for DSA key lengths  
>> between
>> 512 and 1024 bits.  Given that other organizations are moving
>> to a minimum key length of 2048 bits, the IESG wishes to verify IETF
>> consensus for the cryptographic minimums in this document.
>>
>
> The relevant excerpt from the Last Call for 'Secure/Multipurpose  
> Internet Mail Extensions (S/MIME) Version 3.2 Message  
> Specification',  <draft-ietf-smime-3851bis-08.txt>

Here is what Section 4.3 says:

    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)

It strikes me that, if we raise the lower limit from 512 to 1024, all  
of the implementations that conformed to the old specification would  
still conform to the new one.   I strongly support such a change.   
(The same goes for the DSA table.)

It is sensible to allow receiving agents to verify signatures that  
were created with short keys in order to provide interoperability,  
especially in the "legacy" case.  However, I don't see any text that  
describes this motivation.  It would be useful to add a statement  
like: "Key sizes lower than <whatever> bits are included in order to  
promote interoperability, even though those key sizes are not  
recommended for use by signing agents, because they do not provide an  
adequate level of security."

best,

David

>
>
>>
>> In particular, the IESG solicits comments on the cryptographic  
>> strength
>> requirements specified in section 4.1 through 4.5, and the following
>> statement from Section 6, Security Considerations:
>>
>>   "Today, 512-bit RSA, DSA and DH keys are considered by many experts
>>   to be cryptographically insecure."
>>
>> These sections allow the continued use of RSA, DSA, and DH key  
>> lengths
>> between 512 and 1024 bits.  Given that other organizations are moving
>> to a minimum key length of 2048 bits, the IESG wishes to verify IETF
>> consensus for the cryptographic minimums in this document.
>>
>
> I am currently planning to place these documents on the December 18,  
> 2008 IESG telechat.
>
> Thanks,
>
> Tim Polk
>