Re: [Cfrg] CCM

David:

Thank you for taking the time to review the CCM Internet-Draft.  Please 
seem my responses below.

> > The proof is now available.  I sent it to you.  I have also sent it to
> > NIST, so hopefully it will be put on their web site for everyone to fetch.
>
>OK, here are my comments:
>
>  - the security proof depends on the fact that the nonce N is independent
>    of any previous ciphertext. The draft only says that it must be
>    unique. Actually, it's not sufficient that it be unique: it must
>    also be impossible for an attacker to influence the choice of nonce.

In many cases the nonce values are completely predictable.  In fact, IEEE 
802.11 will construct the nonce by concatenating the sender MAC address and 
a packet counter.

>  - the "additional authenticated data" corresponds to the "label" of a
>    Data Encapsulation Method as defined in [Shoup01]. Please mention this
>    correspondance.

I never thought about it this way.  I think about it as a packet with an 
authenticated plaintext header and an authenticated ciphertext 
payload.  What audience would be helped by the "label" reference?

>  - the security proof paper uses different names for some variables
>    (a -> H and m -> M), and also refers to the label as the "header".
>    The draft and the paper should be consistent (it doesn't matter
>    which one is changed). Section 2.3 of the paper should probably
>    also fully describe the encoding function in the draft, for
>    completeness.

This is a problem when things are developed in parallel.  Obviously, you 
were not confused.  I do not see the CCM Proof being published as an 
Informational RFC.  A version of the CCM Proof will be in the proceedings 
of SAC.

>  - the bit numbering convention for the Flags field is not explicitly
>    stated (I assume it's that bit k has weight 2^k). Since octet values
>    are integers from 0 to 255, it would be clearer to specify how the
>    Flags field is encoded as an integer:
>
>      Flags = 64*Adata + 8*M + L  (in section 2.2)
>    and
>      Flags = 8*M + L             (in section 2.3)

I have no objection to adding a formula to describe the same thing. If it 
helps someone understand, then it is useful.  I will make the additions.

I think you have the wrong formula for section 2.3.  It should be: Flags = L.

>  - the draft assumes that the interface to the block cipher is defined in
>    terms of octet strings. The AES FIPS strictly speaking only defines the
>    interface to AES in terms of bit strings. The draft should therefore
>    specify that when used with AES, the most significant bit of each octet
>    corresponds to the first bit of the octet as defined by the AES FIPS.
>    (This is in practice what all AES implementations do.)

Please point me to the text where this is confusing.

>  - in section 2.4:
>    # The final result c consists of the encrypted message m, followed by
>    # the encrypted authentication value U.
>
>    U is indeed the encrypted authentication value, but m is the variable
>    name for the plaintext message.

Okay.  I will change it to: "The final result c consists of the encrypted 
message followed by the encrypted authentication value U."

>  - decryption should be described more explicitly in section 2.5, rather
>    than having to be inferred from encryption.

Several implementors have found this to be sufficient to build 
interoperable implementations.  In fact, many of them have been made freely 
available.  Doug Whiting has pointers to the ones that we know about from: 
http://www.hifn.com/support/ccm.htm.

I am not saying that it could not be made better, but I do think that it is 
good enough...

>  - in section 2.6:
>    # All implementations MUST limit the total amount of data that is
>    # encrypted with a single key.  The sender MUST ensure that the total
>    # number of block cipher encryption operations in the CBC-MAC and
>    # encryption together does not exceed 2^61.
>
>    (2^61 * 16)/2 octets is 16 exabytes (~ 16 million terabytes).
>    It's extremely unlikely that this amount of data would (or could)
>    be encrypted with a single key, even if an implementation did not
>    include an explicit check. However, this paragraph could be
>    interpreted as requiring that implementations include an explicit
>    check, and that protocols include some mechanism for changing keys
>    that will increase the protocol complexity, even though these
>    are unlikely to ever be triggered in practice.

Good point. How about the following: "To preserve security, implementations 
need to limit the total amount of data that is encrypted with a single key; 
the total number of block cipher encryption operations in the CBC-MAC and 
encryption together cannot exceed 2^61.  (This allows nearly 2^64 octets to 
be encrypted and authenticated using CCM.  This is roughly 16 million 
terabytes, which should be more than enough for most applications.)  In an 
environment where this limit might be reached, the sender MUST ensure that 
the total number of block cipher encryption operations in the CBC-MAC and 
encryption together does not exceed 2^61.  Receivers that do not expect to 
decrypt the same message twice MAY also check this limit."

>  - it might be useful to use this mode with block ciphers (or PRFs) that
>    encrypt > 16-octet blocks in future. It would be no more complicated
>    to define the mode generically for z-octet blocks (provided that z >= M,
>    and z-1-L octets is large enough for the nonce).

You are correct.  It is also very straightforward to translate the 
specification to another block size when it is needed.  Given the number of 
people that have already chosen to implement CCM, I am reluctant to make 
significant changes for non-security reasons.

>  - the draft should informatively reference the security proof paper.

Agree.  I did not have a reference at the time it was written.

>  - before the draft is published as an RFC, someone should write an
>    independent implementation and check that it matches the test vectors
>    in section 8.

Already done.  The first two implementations confirmed the test 
vectors.  They are both referenced  on the web page.  Many thanks to John 
Viega and Doug Whiting for their efforts.

Russ
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg