Skip to main content

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

Yes

(Sean Turner)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Stewart Bryant)

Note: This ballot was opened for revision 07 and is now closed.

Sean Turner Former IESG member
Yes
Yes (for -07)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -07)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -07)

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-10-23 for -07)
Not the expert on that topic. No feedback.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07)

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -07)

                            
Richard Barnes Former IESG member
No Objection
No Objection (2013-10-23 for -07)
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-10-22 for -07)
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?
Stephen Farrell Former IESG member
No Objection
No Objection (2013-10-23 for -07)
- 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.
Stewart Bryant Former IESG member
No Objection
No Objection (for -07)

                            
Ted Lemon Former IESG member
No Objection
No Objection (2013-10-23 for -07)
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?