Hi Rob,
Robert Zuccherato wrote:
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?
I don't want to get into into clock synchronisation issues, so an expiry time
would be
bad. A TTL might be ok, but I'd suspect that its easier for an application
using this
scheme to guess or know the maxDecrypts value rather than a TTL.
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?
Protection is not disallowed, just out of scope for this draft.
These possibilities should at least be mentioned in the Security
Considerations.
Fair enough, will add some more text along these lines.
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.
Though I agree with you, its clear that others don't (e.g. Russ), so it looks
like we have to include some 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.
I'm perfectly happy to change this to whatever folks prefer. The current
one is ad-hoc as you say, its (only?) benefit is that it only needs the
content encryption algorithm, but I'm not sure if that's significant.
What do others think?
Stephen.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane, fax: +353 1 647 7499
Dublin 2. mailto:stephen(_dot_)farrell(_at_)baltimore(_dot_)ie
Ireland http://www.baltimore.com