The IESG has approved the following document: - 'AES-CCM ECC Cipher Suites for TLS' (draft-mcgrew-tls-aes-ccm-ecc-08.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/ Technical Summary The document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC Mode (CCM) in several TLS ciphersuites. AES-CCM provides both authentication and confidentiality and uses as its only primitive the AES encrypt operation (the AES decrypt operation is not needed). This makes it amenable to compact implementations, which is advantageous in constrained environments. The use of AES-CCM has been specified for IPsec ESP and 802.15.4 wireless networks. The document utilizes the AEAD facility within TLS 1.2 (RFC5246) and the AES-CCM-based AEAD algorithms defined in RFC5116 and RFC6655. All of these algorithms use AES-CCM; some have shorter authentication tags, and are therefore more suitable for use across networks in which bandwidth is constrained and message sizes may be small. The ciphersuites defined in this document use Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) as their key establishment mechanism; these ciphersuites can be used with DTLS (RFC6347). Working Group Summary The document was proposed to the TLS working group. The TLS working group did not believe it needed WG adoption and suggested publication as an individual submission. It was suggested that the intended status be informational to bring it inline with RCC 5289. There was some concern regarding adding yet more ciphersuites for TLS however RFC 6655 was published which does set a precedent for the use of AES-CCM-based ciphersuites. Document Quality There are numerous existing implementations of the protocol as it is currently being adopted and tested by ZigBee Alliance members involved in the development of the ZigBee IP stack and Smart Energy Profile version 2 (SEP2). There are currently 7 independent vendors implementing the protocol for ZigBee IP and over 20 for SEP2. The ciphersuites are also specified for use with CoAP (draft-ietf-core-coap) in conjunction with DTLS. Personnel The Document Shepherd is Robert Cragie. The Responsible Area Director is Sean Turner. RFC Editor Note Please make the following changes: 1) In Section 1: OLD: This document describes the use of Advanced Encryption Standard (AES) [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS ciphersuites. AES-CCM provides both authentication and confidentiality and uses as its only primitive the AES encrypt operation (the AES decrypt operation is not needed). NEW: This document describes the use of Advanced Encryption Standard (AES) [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS ciphersuites. AES-CCM provides both authentication and confidentiality (encryption and decryption) and uses as its only primitive the AES encrypt block cipher operation. 2) In Section 2: OLD: o The server's certificate SHOULD contain a suitable ECC public key, SHOULD be signed with a suitable ECC public key, and the elliptic curve and hash function SHOULD be selected to ensure a uniform security level; guidance on acceptable choices of hashes and curves that can be used with each ciphersuite is detailed in Section 2.2. The Signature Algorithms extension (Section 7.4.1.4.1 of [RFC5246]) SHOULD be used to indicate support of those signature and hash algorithms. If a client certificate is used, the same criteria SHOULD apply to it. NEW: o If the server uses a certificate, then the requirements in RFC 4492 apply: â??The server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.â?? Guidance on acceptable choices of hashes and curves that can be used with each ciphersuite is detailed in Section 2.2. The Signature Algorithms extension (Section 7.4.1.4.1 of [RFC5246]) SHOULD be used to indicate support of those signature and hash algorithms. If a client certificate is used, the same criteria SHOULD apply to it. 3) In the Security Considerations: OLD: The IV construction in Section 2 is designed to prevent counter reuse. NEW: The IV construction in Section 2 is designed to prevent counter reuse.
