Sean et al:
How about:
0 < key size < 512 : MAY but refer to security considerations
section
512 <= key size < 1024 : SHOULD- but refer to security considerations
section
1024 <= key size <= 2048 : MUST
2048 < key size : MAY but refer to security considerations
section
For larger keys, some text for the security considerations section might
be added, e.g. something like:
"A denial of service opportunity may exploitable by attackers who provide
an excessively large key, or a key selected to require excessive
cryptographic processing. One mitigation approach would require that the
corresponding public key certificate be validated to a trusted root [trust
anchor] prior to use, thus ensuring that only trusted public keys are
used. However, some implementations may choose to perform signature
verification (or data encryption) in parallel with certificate validation,
or even if certificate validation fails. In such cases, measures should
be included to limit the impact, for example by limiting cryptographic
processing time or requiring certificate validation prior to the use of
large keys."
For smaller keys, this is already addressed to some extent for encryption
in the security considerations section, maybe this needs updating based on
our experience with smime:
Current text:
40-bit encryption is considered weak by most cryptographers. Using
weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the
specification of tripleDES 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.
Proposed Draft text:
"Using weak cryptography in S/MIME offers little actual security over
sending plaintext.
Some cryptographers consider public keys of less than 1024* bits to be
weak, along with symmetric encryption algorithms of less than 64 bits and
certain older hash algorithms used for signing.
In any given application, an appropriate analysis of the threats and risks
SHOULD lead to the selection of appropriate algorithms and key sizes.
For public keys, algorithms and key sizes are normally defined by the
public key issuer in the corresponding certificate, and thus not under the
control of the end user.
For symmetric encryption and hash algorithms, S/MIME supports the ability
of parties to communicate their capabilities to each other, allowing the
use of appropriately strong measures.
When feasible, sending and receiving agents SHOULD inform senders (prior
to transmission) and recipients of the relative cryptographic strength of
messages and SHOULD provide a warning if weak algorithms or key sizes are
used.
Such warnings are especially important if the symmetric encryption or hash
algorithm are significantly weaker than the corresponding public key,
since this will result in a message with weaker security than that implied
by the public key certificate. "
Tony
* of course this could be a smaller value.
PS: sorry about earlier e-mail with opaque signing, I did a "Reply to"
which copied the security properties from Timothy's e-mail (but not
cleartext option!) - defaulting to signing which I did not intend!!!
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Timothy
J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; ietf-smime(_at_)imc(_dot_)org
| Subject: Re: S/MIME v3.2 IDs key size text
|
|
|
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >> 0 < key size < 511 : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
|
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to
| verify a
| > signature even though it is valid" is pretty offensive.
|
| How about adding a "MUST warn the user that key is too damn short to
| be considered safe, even though the signature is valid"
| clause instead?
|
| -- Tim
|
|
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Timothy
J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; ietf-smime(_at_)imc(_dot_)org
| Subject: Re: S/MIME v3.2 IDs key size text
|
|
|
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >> 0 < key size < 511 : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
|
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to
| verify a
| > signature even though it is valid" is pretty offensive.
|
| How about adding a "MUST warn the user that key is too damn short to
| be considered safe, even though the signature is valid"
| clause instead?
|
| -- Tim
|
|