Skip to main content

AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC 7251

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from mcgrew@cisco.com, dbailey@rsa.com, mcampagna@certicom.com, rdugal@certicom.com, draft-mcgrew-tls-aes-ccm-ecc@ietf.org, robert.cragie@gridmerge.com, rdroms.ietf@gmail.com to rdroms.ietf@gmail.com
2014-06-26
08 (System) RFC published
2014-05-22
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-05-07
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-04-24
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-04-07
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-04-04
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-03-14
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-03-04
08 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-03-04
08 (System) RFC Editor state changed to EDIT
2014-03-04
08 (System) Announcement was received by RFC Editor
2014-03-04
08 (System) IANA Action state changed to In Progress
2014-03-04
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-03-04
08 Amy Vezza IESG has approved the document
2014-03-04
08 Amy Vezza Closed "Approve" ballot
2014-03-04
08 Amy Vezza Ballot approval text was generated
2014-03-04
08 Amy Vezza Ballot writeup was changed
2014-02-12
08 David McGrew IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-02-12
08 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-08.txt
2014-01-31
07 Sean Turner Changed consensus to Yes from Unknown
2013-12-13
07 Sean Turner Ballot writeup was changed
2013-12-13
07 Sean Turner Ballot writeup was changed
2013-10-31
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake.
2013-10-24
07 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2013-10-24
07 Meral Shirazipour Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Meral Shirazipour.
2013-10-24
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-23
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-10-23
07 Ted Lemon
[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 …
[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?
2013-10-23
07 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-10-23
07 Richard Barnes
[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 …
[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.
2013-10-23
07 Richard Barnes Ballot comment text updated for Richard Barnes
2013-10-23
07 Richard Barnes
[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 …
[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?
2013-10-23
07 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-10-23
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-23
07 Stephen Farrell
[Ballot comment]

- While I hate to see more TLS ciphersuites being added to the
zoo, these will be used as the algs are baked …
[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.
2013-10-23
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-23
07 Benoît Claise [Ballot comment]
Not the expert on that topic. No feedback.
2013-10-23
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-10-23
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-22
07 Spencer Dawkins
[Ballot comment]
This might not even be a comment, but a question. In Section 1.  Introduction,

  This document describes the use of Advanced Encryption …
[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?
2013-10-22
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-10-22
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-10-19
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-10-18
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-10-17
07 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-10-17
07 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-10-15
07 Sean Turner
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 …
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.
2013-10-15
07 Sean Turner Ballot has been issued
2013-10-15
07 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-10-15
07 Sean Turner Created "Approve" ballot
2013-10-15
07 Sean Turner Ballot writeup was changed
2013-10-15
07 Sean Turner State changed to IESG Evaluation from Waiting for Writeup
2013-10-10
07 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2013-10-10
07 Cindy Morgan Note field has been cleared
2013-10-10
07 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-10-10)
2013-10-08
07 Sean Turner Placed on agenda for telechat - 2013-10-24
2013-09-24
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-09-24
07 Amanda Baber
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 …
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.
2013-09-19
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-09-19
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-09-12
07 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-09-12
07 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-09-12
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-09-12
07 Amy Vezza
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) …
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/



2013-09-12
07 Amy Vezza State changed to In Last Call from Last Call Requested
2013-09-12
07 Sean Turner Last call was requested
2013-09-12
07 Sean Turner Ballot approval text was generated
2013-09-12
07 Sean Turner Ballot writeup was generated
2013-09-12
07 Sean Turner State changed to Last Call Requested from AD Evaluation::AD Followup
2013-09-12
07 Sean Turner Last call announcement was generated
2013-08-30
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-08-30
07 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-07.txt
2013-06-20
06 Cindy Morgan Document shepherd changed to Robert Cragie
2013-06-20
06 Sean Turner Document shepherd changed to (None)
2013-06-20
06 Sean Turner Document shepherd changed to (None)
2013-06-20
06 Sean Turner Changed document writeup
2013-05-21
06 Sean Turner
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 …
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.
2013-05-21
06 Sean Turner State changed to AD Evaluation::Revised I-D Needed from AD is watching
2013-02-22
06 Sean Turner State changed to AD is watching from Dead
2013-02-01
06 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-06.txt
2013-01-17
05 (System) Document has expired
2013-01-17
05 (System) State changed to Dead from AD is watching::Revised ID Needed
2013-01-02
05 Sean Turner State changed to AD is watching::Revised ID Needed from AD is watching
2013-01-02
05 Sean Turner Notification list changed to : mcgrew@cisco.com, dbailey@rsa.com, mcampagna@certicom.com, rdugal@certicom.com, draft-mcgrew-tls-aes-ccm-ecc@tools.ietf.org, robert.cragie@gridmerge.com, rdroms.ietf@gmail.com
2013-01-02
05 Sean Turner Note added 'Robert Cragie (robert.cragie@gridmerge.com) is the document shepherd.'
2012-07-18
05 Sean Turner Whoops hit the wrong button when I put it in AD Evaluation.
2012-07-18
05 Sean Turner State changed to AD is watching from AD Evaluation
2012-07-18
05 Sean Turner State changed to AD Evaluation from Dead
2012-07-18
05 Sean Turner
2012-07-16
05 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-05.txt
2012-07-09
04 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-04.txt
2012-05-31
03 David McGrew New version available: draft-mcgrew-tls-aes-ccm-ecc-03.txt
2012-04-20
02 (System) Document has expired
2012-04-20
02 (System) State changed to Dead from AD is watching::Revised ID Needed
2012-02-08
02 Sean Turner State changed to AD is watching::Revised ID Needed from AD is watching.
2012-02-08
02 Sean Turner Draft added in state AD is watching
2012-02-08
02 Sean Turner Setting stream while adding document to the tracker
2012-02-08
02 Sean Turner Stream changed to IETF from
2011-10-18
02 (System) New version available: draft-mcgrew-tls-aes-ccm-ecc-02.txt
2011-07-25
02 (System) Document has expired
2011-01-19
01 (System) New version available: draft-mcgrew-tls-aes-ccm-ecc-01.txt
2010-11-02
(System) Posted related IPR disclosure: Certicom Corp. Statement about IPR Related to draft-mcgrew-tls-aes-ccm-ecc-00
2010-07-06
(System) Posted related IPR disclosure: Certicom's Statement of IPR relating to draft-mcgrew-tls-aes-ccm-ecc-00
2010-07-05
00 (System) New version available: draft-mcgrew-tls-aes-ccm-ecc-00.txt