Earlier, I proposed a replacement for part of the security
considerations in 3851bis (S/MIME message). The current text reads:
Larger keys are not necessarily better keys. Larger keys take more
computational resources, and this can quickly become impractical. In
fact, support for an excessively large key offers a denial of service
opportunity if the attacker can cause excessive cryptographic
processing by providing such a public key. One mitigation approach
would require that the corresponding public key certificate be
validated to a trust anchor prior to use, thus ensuring that only
trusted public keys are used. However, some implementations may
choose to perform signature verification (or key establishment for
encryption) in parallel with certificate validation, 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.
There is no parallel text in 3850bis.
There has been some good discussion, and I now propose different,
more general wording that should be included in both documents. This
would replace the above paragraph in 3851bis and be added to 3850bis.
Sending and receiving agents need to be cautious of CPU usage and
other resources when handling public keys larger than those mandated
in this specification (that is, larger than 2048 bits). For example,
an attacker can send very large, bogus signatures in order to swamp
the CPU of the receiving party. Another example is that an attacker
can try to cause a sender to try to encrypt with a very large key.
One mitigation approach would require that the corresponding public
key certificate be validated to a trust anchor prior to use, thus
ensuring that only trusted public keys are used. However, some
implementations may choose to perform signature verification (or key
establishment for encryption) in parallel with certificate
validation, even if certificate validation fails. Sending and
receiving parties are advised to have some sort of resource
management system to prevent such attacks.