[Cfrg] Re: draft-housley-ccm-mode-00.txt

"Housley, Russ" <rhousley@rsasecurity.com> Wed, 28 August 2002 23:52 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24959 for <cfrg-archive@odin.ietf.org>; Wed, 28 Aug 2002 19:52:35 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SNrfv30968 for cfrg-archive@odin.ietf.org; Wed, 28 Aug 2002 19:53:41 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SNrfo30965 for <cfrg-web-archive@optimus.ietf.org>; Wed, 28 Aug 2002 19:53:41 -0400
Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24950; Wed, 28 Aug 2002 19:52:04 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SNqlo30938; Wed, 28 Aug 2002 19:52:47 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SNpwo30916 for <cfrg@optimus.ietf.org>; Wed, 28 Aug 2002 19:51:58 -0400
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com []) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24934 for <cfrg@ietf.org>; Wed, 28 Aug 2002 19:50:21 -0400 (EDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for odin.ietf.org []) with SMTP; 28 Aug 2002 23:51:50 UT
Received: from ebola.securitydynamics.com (ebola.securid.com []) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA06710 for <cfrg@ietf.org>; Wed, 28 Aug 2002 19:51:19 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost []) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7SNn4S24328 for <cfrg@ietf.org>; Wed, 28 Aug 2002 19:49:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVNLP4>; Wed, 28 Aug 2002 19:51:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP []) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVNLP3; Wed, 28 Aug 2002 19:51:13 -0400
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Jack Lloyd <lloyd@acm.jhu.edu>
Cc: cfrg@ietf.org
Message-Id: <>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 28 Aug 2002 16:39:11 -0400
In-Reply-To: <Pine.LNX.4.33L2.0208151912200.28959-100000@sol.galaxy.acm. jhu.edu>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [Cfrg] Re: draft-housley-ccm-mode-00.txt
Sender: cfrg-admin@ietf.org
Errors-To: cfrg-admin@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>


Thanks for reviewing the document.  See my response below.

>I have some comments and questions regarding the CCM draft, in particular
>Section 2.5
>    [...]
>    If the T value is not correct, the receiver MUST NOT reveal any
>    information except for the fact that T is incorrect.  The receiver
>    MUST NOT reveal the decrypted message, the value T, or any other
>    information.
>For large messages, these MUST NOTs could be quite a problem. Specifically,
>it seems to mean that the recieving side must buffer the entire (supposed)
>plaintext in memory until such a time that the MAC is verified (ie not
>sending it to a file or elsewhere). This could be exceedingly expensive,
>particularly on small machines and large messages.

I understand your concern.  We envision the use of CCM in packet 
environments, where this is not a problem.  Likewise, it would not be a 
problem for an SSL record.  It could be a problem for file encryption.

That said, I think that there is a security concern if plaintext is 
released before the integrity of the plaintext is verified.  The use of 
counter mode, where the key stream is XORed with the plaintext to generate 
the ciphertext, makes the integrity checking a very important aspect of the 
overall security processing.

Cfrg mailing list