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

Stephen Farrell <stephen.farrell@baltimore.ie> Fri, 15 September 2000 11:29 UTC

Message-ID: <39C20375.961C5C64@baltimore.ie>
Date: Fri, 15 Sep 2000 12:09:41 +0100
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
MIME-Version: 1.0
To: Robert Zuccherato <robert.zuccherato@entrust.com>
CC: ietf-smime@imc.org, xme <stephen.farrell@baltimore.ie>
Subject: Re: Comments on draft-ietf-smime-rcek-00.txt
References: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

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.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Comments on draft-ietf-smime-rcek-00.txt Robert Zuccherato
Re: Comments on draft-ietf-smime-rcek-00.txt Russ Housley
Re: Comments on draft-ietf-smime-rcek-00.txt Stephen Farrell