| -----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 Paul
Hoffman
| Sent: August 6, 2008 11:07 AM
| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
| Cc: ietf-smime(_at_)imc(_dot_)org
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
|
|
cut
|
| Proposed wording:
|
| Receiving agents that validate signatures need to be cautious of CPU
| usage when validating signatures larger than those mandated in this
| specification. An attacker can send very large, bogus signatures in
| order to swamp the CPU of the receiving party. Receiving parties that
| verify large signatures are advised to have some sort of resource
| management system to prevent such an attack.
|
I agree with the intent here, but this issue applies to both signature and
encryption operations.
So the text needs to address both sections /4.3 Signature Verification/ and
/4.4 Encryption/
(/4.5 Decryption/ should be ok since I presume the agent is using a validated
decryption key)
So maybe the last line of both sections could change to:
"2048 < key size : MAY (see Security Considerations, and
especially discussion of denial
of service vulnerability when
implementing support for large keys,
e.g. keys larger than 4096.)"
Similarly maybe it is also appropriate* to add the same text to rfc3850bis-04
section /4.3 Certificate and CRL Signing Algorithms/
And the security considerations section of rfc3850bis updated similarly to 3851
with regard to cautions about large key sizes.
Tony
*Also a problem for cert validation if the provided intermediate cert has a
large key (which would be used to check the end user certificate signature).
Hopefully implementers will either a) identify the chain of certificates and
begin validation at the trust anchor or b) limit crypto processing in some way.