Re: Comments on draft-ietf-smime-rcek-00.txt

[Stephen Farrell <[e-mail]>]

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com