AES-CCM Cipher Suites for Transport Layer Security (TLS)
RFC 6655

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)
No email
send info
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)
No email
send info
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?

(Robert Sparks) No Objection

(Russ Housley) Recuse