I don't believe we need AES-CCM. Ideally, we would only support one or two ciphersuites at a time, and I intend to emulate BoringSSL in not exposing any choice of ciphersuite in TLS 1.3, selecting the fastest between AES-GCM and ChaCha20 based on hardware support (or the one preferred by the client based on PreferServerCipherSuites). As long as the default is fast and secure, the end user shouldn't have to make a decision on cipher block modes.

I don't think there's a fairness argument to the number of choices, as long as most users are served by the available options. If you believe I'm missing a concrete use case for AES-CCM that's not covered by the other supported ciphersuites, please do follow up.

@FiloSottile the missing use case is quite simple: IoT device where using AES-CCM is faster/consumes less than AES-GCM and connecting through TLS to a cloud service implemented in golang.

I disagree @FiloSottile, most of the current battery-powered IoT devices doesn't have accelerated Galois mode of authentication which force us to use the software based ChaCha20-Poly1305.

That is a deal breaker for lots of devices already deployed where only hardware-accelerated AES is available. In our internal tests AES (HW), CCM (SW) is much more efficient (for a battery draining POV) than ChaCha20-Poly1305. Although there are already known flaws in AES-CCM combo I think it's worth implementing it.

Perhaps you can tell me why does IETF board included this cipher combo in TLS 1.3?

Can you reconsider this?

I'm reopening this to see how popular this request is and to look more into the AES-CCM mode (what "known flaws" are you referring to?), but 1) crypto/tls takes a minimalist approach, and 2) carrying a performant AES-CCM would probably cause us to carry extra assembly implementations, which is a deal-breaker at least for now.

Thanks at least for thinking it twice.

1. More than flaws, they are probable attacks:
   • https://wiki.newae.com/AES-CCM_Attack
   • https://eprint.iacr.org/2015/529.pdf
2. Why not just a pure-go implementation for the initial phase?

I'm also finding myself in need of an AES-CCM implementation to communicate with an IoT device (Custom protocol, not TLS, though). And again, AES-CCM is the cipher of choice due to having hardware-accelerated AES.

So +1 on this.

(Also, the attacks linked above are power analysis attacks against hardware implementations. They're not cryptanalytic attacks against the algorithm itself. I don't believe they are reasons to not include CCM)

In case this proposal gets approved there is a valid CCM implementation at https://github.com/bocajim/dtls

I have submitted a MR (golang/crypto#62) but it was denied because I am not the author of the code and because this proposal must be approved first.

/cc @bocajim @jimwert

Friendly ping, including also to (maybe) interested parties (@agl @bradfitz)

The cost of carrying assembly implementations has unfortunately not improved, so this is still on hold for the same reasons here #27484 (comment).

What about an AES-CCM implementation without assembly optimizations? This will allow IoT devices with AES acceleration to connect to a server running golang code even if the server is not optimized. The bottleneck here will be probably the IoT device, not the server anyway.

I second @igolaizola proposal. CCM is largely useful for communicating with IoT devices/gateways, so not having assembly optimised implementations is unlikely to be a source of problems. It would be nice to not have this requirement hold it back but land CCM support so that when the need arises we can improve by adding the assembly in future versions.

I'm currently looking at lifting bocajim/dtls CCM implementation into pions/dtls so we can end up with one DTLS library supporting all use cases, but it would be great to have this in stdlib instead and avoid needing to carry that code.

Is the any progress going on? as above comments mentions it will be helpful if is CCM implementation (no necessarily hardware accelerated) makes into standard library, i am also in need for CCM to communicate with IoT gateway.

@newmanifold If it can help you, feel free to take a look at https://github.com/pion/dtls/tree/master/internal/crypto/ccm

@FiloSottile Can we get you to take another look at this, please? We're not looking to add assembly, which seems to be the biggest concern that was brought up previously. People are just looking for a pure-Go additional as a first step to stdlib.

I'm testing Yubico YubiHSM's import/export functionality that uses AES-CCM for wrapping private keys. I thought I'll whip up a quick encoder/decoder in Go to prove that the algorithm works as intended. (It doesn't, that's why I wanted to confirm using software.)

Apparently, I'm going to "whip up" a "quick" encoder/decoder in C, using OpenSSL libraries. :(

@ianlancetaylor My apologies for the ping, but the "on-hold" label was added to this over 4 years ago. So even though it's open it's essentially in limbo, based initially on the belief that this would mean carrying assembly implementations which at the time was deemed a deal breaker.

I think it would be nice to re-evaluate that and if necessary close it to at least put this to bed. I don't think the assembly implementations are required, at least not as a first step to adding CCM support as has been pointed out by a number of people.

The discussion above from 2018 sounds like we don't want to add this because we want a limited number of well-tested algorithms in crypto/tls and not all possible algorithms. There was some question about whether AES-CCM is needed on certain devices, which might make it more important. I still don't quite see that evidence here though. Why is CCM needed?

It sounds like AES-CCM may be preferred on IoT devices over AES-GCM because it is less computationally expensive and uses less power. On the other hand, #27484 (comment) suggests there may be attacks against it, which is one reason we'd leave it out. It's unclear how to balance those.

#27484 (comment) about YubiKey wrapping of private keys does not seem like it would use crypto/tls, only AES-CCM. That can be obtained from a third-party library easily. What's not easy is integrating it into crypto/tls.

@FiloSottile, @rolandshoemaker, @golang/security, thoughts?

If, due to IOT, CCM is actually becoming somewhat widespread, it seems reasonable to reconsider our stance on pulling in support for crypto/tls (other use cases are less interesting in terms of standard library support). I'd like to see some data, if anyone has any, on actual usage.

Looking at the suggested attacks, those are both reliant on power side channel analysis, but I don't think we've ever considered those types of attacks within our threat model.

I think our main stumbling block here is that, given the current structure of the AES implementations, in order to get an optimized implementation we'd need a giant new hunk of assembly as we've not split out the common AES core from the other cipher modes. Perhaps we'd accept a pure-go implementation, for now, and once we clean up the AES assembly we could look towards optimizing, but that would mean it would be ~slow for a while.

Currently we carry an AES-CCM implementation in pion/dtls as it's required for CoAP. Specifically TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 are mandated. In practice it means anyone deploying IoT devices using CoAP would have a need for it. At least one residential product uses this that I'm aware of, which is the IKEA Tradfri Gateway (and the reason I added AES-CCM support to Pion). I don't have figures on how many other devices are using CoAP though. Though CoAP runs over UDP, hence dtls, it may give you a sense of real life deployments. Perhaps a go-coap developer like @jkralik might have some numbers.

As far as I know, WPA2's CCMP mode is also based on AES-CCM. Zigbee uses a derivative called CCM* to allow for encryption only. In practice AES-CCM is in use all around you, people generally just don't realise 🙂.

For Pion we don't carry optimised assembly implementations, because they're hard to maintain and none of the maintainers at the time felt comfortable taking that on. We've considered doing so in the past by leveraging Avo. We've had a "performance" issue in the past where CCM ended up getting selected over other more performant ciphers when available. This was mostly a bug in us advertising CCM support by default and accidentally prioritising it. This is something we changed to be opt-in (as in you have to explicitly enable CCM ciphers). Aside from that one case, we've never had someone raise issues with the AES-CCM performance in the past 4-5 years so thus far we've only ever carried a pure-go implementation.

+1 from FIDO Alliance regarding IoT. Our FDO protocol supports CCM, and we have vendors that do use it. It's a pain that it's not a core crypto suite.

One other case to add to the list; when exporting/importing keys using wrapped keys from/to an HSM, AES-CCM is used in some case for the wrapping key. YubiHSM does it that way for example.