AES-CCM Cipher Suites for Transport Layer Security (TLS)
Note: This ballot was opened for revision 03 and is now closed.
(Sean Turner) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2012-03-11 for -03)
A few easily fixed, but worth fixing, near-nits: 1. RFC 5288 names ciphersuites such as TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 but this draft uses TLS_RSA_DHE_WITH_AES_256_CCM. Why change the order from DHE_RSA to RSA_DHE? If there's no good reason then maybe sticking with DHE_RSA would be better since it'd help with ordered lists and searches when folks want to find out how to do stuff. 2. Even if you don't change these names (as above), the reference to RSA-DHE being in 5288 should probably be fixed since that string doesn't occur in 5288, where DHE_RSA is used, as in 5246. 3. This draft says the RSA and RSA-DHE key exchanges are defined in 5288, but 5288 says that the RSA and DHE_RSA key exchanges are defined in 5246. Why the 2nd indirection? 4. Section 4 has no reference to RFC 4279 which is where PSK stuff is really defined. I think adding that would be good. 5. As above, the ciphersuite naming could be made more consistent. RFC 4279 defines TLS_DHE_PSK_WITH_AES_256_CBC_SHA whereas this draft defines TLS_PSK_DHE_WITH_AES_256_CCM. 6. Section 5 could be more clear about why its a bad idea to negotiate these ciphersuites with TLS 1.1 and below. A pointer to a reference or a short sentence should be enough, just so developers don't ignore this so easily. (It'd maybe be easy to get this wrong for a developer with a TLS1.1 library on a constrained device who's nervous about moving to TLS1.2.) And one that's maybe less easily fixed: 7. Clients using these ciphersuites will not be able to work with random TLS servers on the Internet for quite a while. Would it be worth noting that, so that we don't mis-direct constrained node developers or other SDOs into selecting these in the expectation that they will get the same level of interop as with the ciphersuites that are actually used in the wild? I say that accepting that there are real benefits to these ciphersuites for such clients, but the lack of interop is also a real downside, and one that not all the relevant folks seem to appreciate. (Even if we prefer authenticated encryption and more optimal ciphersuites for constrained nodes, that can force use of hop-by-hop security via some gateway in which case we're no long clearly winning overall.) And finally a non-actionable lament:-) 7. Isn't it a pity 330 ciphersuites wasn't enough already.
(Pete Resnick) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2012-03-12 for -03)
Typo: s/abiltiy/ability/ The missing "T" at the beginning of Section 2 causes the document to fail ID-nits. The cipher names use the "_8" suffix to indicate 8-octet authentication tags, and the lack of a suffix to indicate 16-octet authentication tags. Excuse my ignorance, but are any other lengths allowed in AEAD?