I have a few comments on the draft proposing the re-use of content
encryption keys (draft-ietf-smime-rcek-00.txt).
The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service
attack in two ways. First, the attacker could just resend a message
MaxDecrypt times and the CEKReference would no longer be valid and
potentially not accessible. Does it make more sense to limit the lifetime
of the CEKReference by time (maybe give the number of seconds it is to be
active) instead of number of decrypts? Also, since the attribute is
unprotected it could be changed (i.e. reduced) so that the CEKReference
isn't available as long as intended. Why not allow the attribute to be
protected? These possibilities should at least be mentioned in the Security
Considerations.
Why not just mandate that the CEK and KEK algorithms must be the same? This
wouldn't seem to be too much of an imposition. This removes the need for a
KDF. If you really want to allow different algorithms, the KDF included
seems kind of ad-hoc. I would be more comfortable if a more standard KDF
was used. Perhaps the KDF from IEEE P1363 would be appropriate.
Thanks,
Robert Zuccherato
Entrust Technologies