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

From: "Housley, Russ" <[email-masked]>
Date: Thu, 15 Aug 2002 10:55:32 -0400

Dear CFRG:

I would like to draw your attention to this document.  It contains a 
specification for an authenticated encryption mode.  It was designed fro 
use with AES, but, of course, it will work with any 128-bit block cipher.

The authors have submitted it to NIST for consideration as a FIPS 
mode.  You can learn more about CCM and the other proposed modes at the 
NIST web site ( see http://csrc.nist.gov/encryption/modes/proposedmodes/ ).

IEEE 802.11 has chosen to make CCM the mandatory to implement AES mode for 
wireless LAN encryption. IEEE 802.15 has also chosen CCM for use with 
personal area networks.  In my opinion, this success is due to the lack of 
a patent (or pending patent from the authors) on CCM.  I suspect that most 
of the members of this list are aware that other candidate authenticated 
encryption modes are encumbered.

It is my intention to publish draft-housley-ccm-mode-00.txt as an 
Informational RFC.  This looks like the appropriate group to review the 
document.

Russ

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: [email-masked] (David Wagner)
Date: 15 Aug 2002 19:09:10 GMT

Hi Russ,

Thanks for the advance notice.  As you write your Internet-Draft, can I
encourage you to write a comparison (advantages, disadvantages) between
CCM and the less fancy encrypt-then-authenticate generic composition of
CBC mode encryption and CBC-MAC authentication (suitably modified to be
secure for variable-length messages)?

-- David

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 28 Aug 2002 16:39:11 -0400

Jack:

Thanks for reviewing the document.  See my response below.

>I have some comments and questions regarding the CCM draft, in particular
>about:
>
>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.

Russ