AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
draft-mcgrew-tls-aes-ccm-ecc-08

[Ballot comment]
The document describes these cipher suites as being useful for constrained nodes, but needed on other nodes so that they can interoperate with constrained nodes that use it.  This implies to me that a node that is not constrained might want to use a different algorithm.  I don't have enough of a clue about ciphers to know if this means that this cipher suite is weaker, but that's what I'm tempted to assume.  If in fact it is weaker, then the encouragement to implement it on non-constrained nodes ought to be accompanied by an admonishment never to volunteer to use it when the communicating partner supports a better cipher suite.  Is the fact that I don't see this admonition because it is felt to be obvious, or is made in some other document, or am I just mistaken about the reason behind recommending this cipher suite specifically for constrained nodes?

[Ballot comment]
Like Spencer, I'm confused by the requirement in Section 2 that "the server's certificate SHOULD contain a suitable ECC public key, SHOULD be signed with a suitable ECC public key".  Section 2.2 of RFC 4492 has the following requirement for ECDHE_ECDSA ciphersuites: "In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
  capable public key and be signed with ECDSA."  Isn't that the same as what's in this document, only stronger?

The Security Considerations refers to "The IV construction in Section 2...", but Section 2 refers to the "nonce input".  Should probably change "IV" to "nonce" to align with Section 2 and RFC 6655.

[Ballot comment]
Like Spencer, I'm confused by the requirement in Section 2 that "the server's certificate SHOULD contain a suitable ECC public key, SHOULD be signed with a suitable ECC public key".  Section 2.2 of RFC 4492 has the following requirement for ECDHE_ECDSA ciphersuites: "In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
  capable public key and be signed with ECDSA."  Isn't that the same as what's in this document, only stronger?

[Ballot comment]

- While I hate to see more TLS ciphersuites being added to the
zoo, these will be used as the algs are baked in various bits
of h/w.

- The write up talks about existing implementations. Are the
codepoints really still ok for IANA to pick or has the horse
really left the barn? I'm not asking to encourage naughtiness,
but it'd be a shame if some zigbee stuff was out there already
and wasn't going to be changed.

- The "cert SHOULD be signed with ECC" seems like an odd
SHOULD, I think you mean its more likely to work in more
environments if you use ECC all the way up and don't have any
RSA, but if so, it'd maybe be better to say that.

- A reference to the brainpool curves in TLS RFC in appendix A
would probably be useful.

[Ballot comment]
This might not even be a comment, but a question. In Section 1.  Introduction,

  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).  This makes it
              ^^^ ^^^ ^^^^^^^ ^^^^^^^^^ ^^ ^^^ ^^^^^^

  amenable to compact implementations, which is advantageous in
  constrained environments.  Of course, adoption outside of constrained
  environments is necessary to enable interoperability, such as that
  between web clients and embedded servers, or between embedded clients
  and web servers.

My first interactive programming language was APL, often described as a http://en.wikipedia.org/wiki/Write-only_language ("I can write any program in APL, I just can't read them"), so this made me curious.

I can imagine an implementation for a constrained environment that only encrypts sensor information, and never receives control information, so doesn't need to include decryption, but is it obvious to everyone but me how the encrypted information is used, if there is no defined decrypt operation? Or is this a missing reference to some other specification that describes what you do with the authenticated and encrypted zeros and ones? I'm looking at

  Implementations of these ciphersuites will interoperate with
  [RFC4492], but can be more compact than a full implementation of that
  RFC.

in section 2 - is that related? But I'm just guessing.

If this is a stupid question, I apologize for interrupting, of course. Please carry on.

Also in section 2,

  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. 

I'm not questioning any other SHOULD in the document, but if the server's certificate doesn't contain a suitable ECC public key, can you still do something useful?

My one concern about this cipher suite draft is the additional stipulations found in s2.  Other TLS cipher suites do not provide these, they just list the ciphers period.  I pointed this out to the TLS WG and no one objected.  You should not that they are reasonable, at least in my mind.  Further Appendix A was originally in the mainbody of the draft but it was moved at my request to an appendix because no other draft ECC TLS cipher suite draft mandates a particular curve or set of curves.

IESG/Authors/WG Chairs:

IANA has reviewed draft-mcgrew-tls-aes-ccm-ecc-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the TLS Cipher Suite Registry in the Transport Layer Security (TLS) Parameters page at

http://www.iana.org/assignments/tls-parameters/

four new cipher suites are to be registered as follows:

Value Description DTLS-OK Reference
-------------+------------------------+----------------+-------------
[TBD-at-registration] TLS_ECDHE_ECDSA_WITH_AES_128_CCM Y [ RFC-to-be ]
[TBD-at-registration] TLS_ECDHE_ECDSA_WITH_AES_256_CCM Y [ RFC-to-be ]
[TBD-at-registration] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 Y [ RFC-to-be ]
[TBD-at-registration] TLS_ECDHE_ECDSA_WITH_AES_1256_CCM_8 Y [ RFC-to-be]

IANA understands that this is the only action required to be completed by IANA upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AES-CCM ECC Cipher Suites for TLS) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'AES-CCM ECC Cipher Suites for TLS'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes the use of the Advanced Encryption Standard (AES)
  in the Counter and CBC-MAC Mode (CCM) of operation within Transport
  Layer Security (TLS) to provide confidentiality and data origin
  authentication.  The AES-CCM algorithm is amenable to compact
  implementations, making it suitable for constrained environments.
  The ciphersuites defined in this document use Elliptic Curve
  Cryptography (ECC), and are advantageous in networks with limited
  bandwidth.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1352/
  http://datatracker.ietf.org/ipr/1443/

This draft is needed by both the COAP WG and the Zigbee Alliance.  The only issue with this draft was whether the draft should include MTI curve.  I queried the TLS WG and there was definitely support for the conservative curves chosen but not that much support for keeping the curves in the draft.  I've instructed the authors to remove the curves from the draft and checked informed the COAP & Zigbee folks that they need to make sure the curves are in their drafts.  Turns out the Zigbee folks already had the curves in and the COAP authors seem amenable to incorporating the same MTI curve.  All good.

Waiting on a revised version.

State Change Notice email list changed to mcgrew@cisco.com, dbailey@rsa.com, mcampagna@certicom.com, rdugal@certicom.com, draft-mcgrew-tls-aes-ccm-ecc@tools.ietf.org, rdroms@cisco.com from mcgrew@cisco.com, dbailey@rsa.com, mcampagna@certicom.com, rdugal@certicom.com, draft-mcgrew-tls-aes-ccm-ecc@tools.ietf.org