Subject: Document Action: 'AES-CCM ECC Cipher Suites for TLS' to Informational RFC (draft-mcgrew-tls-aes-ccm-ecc-08.txt)

From: The IESG <[email-masked]>
Date: Tue, 04 Mar 2014 02:51:33 -0800

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.