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

From: Tim Polk <[email-masked]>
Date: Wed, 19 Nov 2008 18:06:38 -0600

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."
>
> 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>

>
> 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.
>

Given the lack of response from the wider community, I would greatly  
appreciate any input the CFRG can provide.

I am currently planning to place these documents on the December 18,  
2008 IESG telechat.

Thanks,

Tim Polk

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 20 Nov 2008 17:23:06 +1300

>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.

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 Nov 2008 12:13:13 -0800

>>   to be cryptographically insecure."

This is definitely a true statement. The agreed-upon equivalencies for  
crypto-balance says that a 512-bit public key corresponds to 56-bit  
symmetric crypto. Many experts think that 56-bit crypto is  
cryptographically insecure. This is a "many" in the same sense that  
"many"  doctors think that smoking is bad for you.

>> consensus for the cryptographic minimums in this document.

I think anyone who is using a key less than 1024 bits is just plain  
daft. Even people using 1024 bit keys need to look deep within their  
soul and ask themselves when they're going to upgrade. (I'm one of  
those people -- I have a 1024-bit DSA key -- and the answer is, "Soon  
and will you stop nagging me?")

Anyone who is creating new keys should be making them larger than  
1024. A 1024-bit public key corresponds to 80-bit security, which NIST  
says ought to be phased out in 2010. This is why I'm being squishy --  
an important use-before date on 1024-bit keys isn't here, but it's  
close enough that new projects will cause themselves problems by using  
1024-bit keys. Better to just go to 2048 now.

	Jon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 20 Nov 2008 16:33:47 -0500

On Thu, 20 Nov 2008 12:13:13 -0800
Jon Callas <[email-masked]> wrote:

> 1024. A 1024-bit public key corresponds to 80-bit security, which
> NIST says ought to be phased out in 2010. This is why I'm being
> squishy -- an important use-before date on 1024-bit keys isn't here,
> but it's close enough that new projects will cause themselves
> problems by using 1024-bit keys. Better to just go to 2048 now.

Strong agreement.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg