Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: crypto/tls: add support for AES-CCM #27484

Open
igolaizola opened this issue Sep 4, 2018 · 15 comments
Open

proposal: crypto/tls: add support for AES-CCM #27484

igolaizola opened this issue Sep 4, 2018 · 15 comments
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues Proposal-Hold
Milestone

Comments

@igolaizola
Copy link

igolaizola commented Sep 4, 2018

Hi! I am working in a project that requires AES-CCM cipher suite within TLS. I know that crypto/tls aims to support a limited safe subset of TLS. But since TLS 1.3 will only support the following cipher suites:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

Reducing that list from 5 to only 3 choices seems pretty unfair.

I've seen some working golang AES-CCM implementations around github. Is there any specific reason why this cipher suite is not included?

Thanks!

Update:
Another option could be to port the code from BoringSSL: https://github.com/google/boringssl/blob/master/crypto/cipher_extra/e_aesccm.c

/cc @FiloSottile @agl

@andybons andybons added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal-Crypto Proposal related to crypto packages or other security issues and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 4, 2018
@andybons andybons changed the title crypto/tls: add support for AES-CCM proposal: crypto/tls: add support for AES-CCM Sep 4, 2018
@gopherbot gopherbot added this to the Proposal milestone Sep 4, 2018
@FiloSottile
Copy link
Contributor

FiloSottile commented Sep 5, 2018

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.

@igolaizola
Copy link
Author

igolaizola commented Sep 6, 2018

@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.

@glerchundi
Copy link

glerchundi commented Sep 13, 2018

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?

@FiloSottile
Copy link
Contributor

FiloSottile commented Sep 13, 2018

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.

@glerchundi
Copy link

glerchundi commented Sep 20, 2018

Thanks at least for thinking it twice.

  1. More than flaws, they are probable attacks:
  2. Why not just a pure-go implementation for the initial phase?

@Dirbaio
Copy link

Dirbaio commented Oct 1, 2018

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)

@igolaizola
Copy link
Author

igolaizola commented Oct 24, 2018

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

@glerchundi
Copy link

glerchundi commented Feb 6, 2019

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

@FiloSottile
Copy link
Contributor

FiloSottile commented Feb 7, 2019

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

@igolaizola
Copy link
Author

igolaizola commented Feb 10, 2019

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.

@daenney
Copy link

daenney commented Mar 26, 2019

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.

@jimwert
Copy link

jimwert commented Mar 26, 2019

@newmanifold
Copy link

newmanifold commented Nov 9, 2019

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.

@daenney
Copy link

daenney commented Nov 12, 2019

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

@daenney
Copy link

daenney commented Nov 20, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues Proposal-Hold
Projects
None yet
Development

No branches or pull requests

9 participants