[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg