[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