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

From: Robert Zuccherato <[email-masked]>
Date: Thu, 14 Sep 2000 11:05:32 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Sep 2000 12:09:41 +0100

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:[email-masked]
Ireland                             http://www.baltimore.com