Tony,
In 3850, I added the (see Security Considerations [SMIME-MSG]) from 4.3 of
3850 to pull in the security consdierations from 3851. We already point to
it normatively so I think this might be better than copying the text in
different places.
spt
-----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 Tony Capel
Sent: Wednesday, August 06, 2008 3:02 PM
To: 'Paul Hoffman'; '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
| -----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.