CCM session modes

[jadamcrain]

I'm implementing IEEE 2030.5 - 2018. The spec requires the CCM bulk encryption AEAD with truncated MAC:

All devices SHALL support the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite (IETF
RFC 7251).

The spec doesn't explicitly state why a less commonly supported mode is required, but I've pieced together that perhaps it's for embedded devices with AES acceleration but not GHASH:

https://crypto.stackexchange.com/questions/63796/why-does-tls-1-3-support-two-ccm-variants

It appears from this thread that rustls doesn't support them because ring lacks support.

We've successfully used rustls to implement two other M2M standards in electric power, but this will unfortunately mean that we have to use native-tls for this project.

My question at this point in time:

Would rustls support these bulk modes in 1.2 and 1.3 if ring implemented them? Is there any concern with adding them beyond the lack of support currently?

Perhaps this can just be a tracking issue in case anyone else runs into this as well. I didn't see any other open issues in the tracker.

[djc]

I can't think of any objections that we would have to implementing CCM in rustls if ring would provide support.

[jadamcrain]

I've opened a PR on ring here.

This would give us the AES_128_CCM but not the AES_128_CCM_8 mode.

Can you point me towards Rustls' TLS 1.2/1.3 bulk mode interfaces? I assume that those interfaces don't care about the Tag size?

Ring currently has a fixed 16-byte size for the AEADs it supports.

[djc]

CipherSuiteCommon has a field aead_algorithm which seems to be what's used for encryption/decryption. QUIC support would additionally want a new BulkAlgorithm variant -- since that enum is part of the public API and not non_exhaustive that part would be an API-incompatible change. The tag_len() method of the ring::aead::Algorithm is used to abstract over the tag length.

[jadamcrain]

I'm hesitant to put any more effort into this b/c ring appears to be where pull requests go to die. Maintainers have constraints, but this situation has become a liability for the long-term viability of Rustls.

We are a small two person shop. Tokio/Rustls is critical to our modest product/consulting offerings. We have small monthly sponsorship donations set up for both.

I think the best thing that could happen would be Rustls forking webpki/ring under their Github org with support from Prossimo. These dependencies are critical components of Rustls and their lack of support is really holding the project back. We'd happily give more to Prossimo, but we're tiny. Finding larger sponsors that depend on Rustls seems like it would be important. Let me know if there's anything I can do to help. I just can't see working on a PR for Rustls that depends on a PR in ring right now.

[jadamcrain]

BTW, I will be at rustconf next week in Portland if anyone from the Rustls team wants to meet up and chat. We are using rustls in industrial protocols:

https://stepfunc.io/products/libraries/

[djc]

@jadamcrain yes, the situation with ring/webpki maintenance isn't great right now -- we'd like to improve on that but doing so is non-trivial since the required competencies are highly specific and relatively rare.

I won't be at RustConf but maybe Brian Smith will be?

[jadamcrain]

Totally fair. I'm glad to see the rustls maintainers recognize this as an issue. That's all that anyone can ask given the constraints you mention.

If the solution is getting the current maintainer (who has done excellent work bringing these projects to production use) more resources I'm supportive of it, but I will say that these projects feel quite siloed (single commit access) as compared to Rustls itself. I would prefer to see a long term solution where a group of maintainers with consistent financial backing assume ownership of these critical projects.

[djc]

I share your preference, all other things being equal.