At 12:14 PM -0400 5/12/08, Tony Capel wrote:
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
Could you add verbs to your table? MAY what? SHOULD- what?
"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."
Regardless of small key size issue, I think text like this would be a
good addition to the Security Considerations section of many
documents.
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.
And some don't consider 1024 bits weak. For example, there are lots
of 1024-bit certificates in the trust anchor pile in your browser. To
date, no one is known to have compromised even one of them, even
though doing so would have higher value than compromising almost any
individual's signing key. Cryptographers who look at the real world
of costs and benefits have noticed this.
In any given application, an appropriate analysis of the threats and risks
SHOULD lead to the selection of appropriate algorithms and key sizes.
That SHOULD is misplaced. Please re-read RFC 2119. Further, we all
know that this sentence is more often false than true in the real
world. What is the advantage of reproducing this fairy tale in the
S/MIME spec?
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.
I'm lost here. Using the protocol described in the document, how
would I send such information? How would I send such a warning?