Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
draft-ietf-ipsec-ciph-aes-ccm-05

[Ballot discuss]
Needs to be fixed, though not really a Discuss:  the Acknowledgments say that CCM is unencumbered by patents, but IETF policy is to have no comment on IPR.  (And alas, one hopes this is true, but someone else may make some claim...).  I cleared my Discuss once Steve supported that this text would be removed.

[Ballot comment]
>        accommodates a full Jumbogram [JUMBO]; however, the length

missing reference.

>    AES-CCM employs counter mode for encryption.  As with any stream
>    cipher, reuse of the IV same value with the same key is catastrophic.

s/IV same/same IV/

[Ballot comment]
A question that is probably for my own education:  a significant issue in the SRTP discussion about AES counter mode was the risk that an attacker could forge an encrypted message that would decode to non-random plaintext, or succeed in an insertion attack, in null or weak authentication.  The Security Area in that case specified strengths by length (of an HMAC-SHA1), requiring at least 96 bits for traffic for which this risk was not tolerable (see draft-ietf-srtp-09.txt, 9.5.1).  Are things hand-wavy enough that the minimum 8 octets is fine?  Is ICV not comparable?  (Not wanting in any way to open any WG  worm-cans that were hard to close, since other drafts that can trade off issues like these really need this document).

[Ballot comment]
A question that is probably for my own education:  a significant issue in the SRTP discussion about AES counter mode was the risk that an attacker could forge an encrypted message that would decode to non-random plaintext, or succeed in an insertion attack, in null or weak authentication.  The Security Area in that case specified strengths by length (of an HMAC-SHA1), requiring at least 96 bits for traffic for which this risk was not tolerable (see draft-ietf-srtp-09.txt, 9.5.1).  Is there a reason why the ICV in CCM doesn't have these risks at 4 or 8 octets?  I noted that the mandatory lengths were longer, and I certainly don't want this document, which is needed by others, where the risks are tradeoffs by the developers, to be controversial as it was in the WG.  Just curious, but no time to research the WG mailing list.

[Ballot discuss]
Needs to be fixed, though not really a Discuss:  the Acknowledgments say that CCM is unencumbered by patents, but IETF policy is to have no comment on IPR.  (And alas, one hopes this is true, but someone else may make some claim...).

[Ballot comment]
A question that is probably for my own education:  a significant issue in the SRTP discussion about AES counter mode was the risk that an attacker could forge an encrypted message that would decode to non-random plaintext, or succeed in an insertion attack, in null or weak authentication.  The Security Area in that case specified strengths by length (of an HMAC-SHA1), requiring at least 96 bits for traffic for which this risk was not tolerable (see draft-ietf-srtp-09.txt, 9.5.1).  Is there a reason why the ICV in CCM doesn't have these risks at 4 or 8 octets?

[Ballot comment]
Needs to be fixed, but I would not call it a Discuss:  the Acknowledgments say that CCM is unencumbered by patents, but IETF policy is to have no comment on IPR.  (And alas, one hopes this is true, but someone else may make some claim...).

A question that is probably for my own education:  a significant issue in the SRTP discussion about AES counter mode was the risk that an attacker could forge an encrypted message that would decode to non-random plaintext, or succeed in an insertion attack, in null or weak authentication.  The Security Area in that case specified strengths by length (of an HMAC-SHA1), requiring at least 96 bits for traffic for which this risk was not tolerable (see draft-ietf-srtp-09.txt, 9.5.1).  Is there a reason why the ICV in CCM doesn't have these risks at 4 or 8 octets?

[Ballot comment]
Nit, section 2, description of AAD (middle of pg4) - "The construction of the AAD described in section 5" perhaps should be "AAD is described in"?

Nit, third line of Section 4 - "The AES counter block 16 octets", perhaps should be "is 16 octets"?

[Ballot comment]
>>Abstract
>>
>>  This document describes the use of AES CCM Mode, with an explicit
>>  initialization vector, as an IPsec Encapsulating Security Payload
>>  (ESP) mechanism to provide confidentiality, data origin
>>  authentication, connectionless integrity.

AES CCM mode should be expanded.  Also, it should be consistently
hyphenated (AES-CCM) or not hyphenated (AES CCM) throughout the
document.