Subject: [core] time to start the deprecation of CCM_8?

From: Thomas Fossati <[email-masked]>
Date: Mon, 18 Oct 2021 14:14:44 +0100

hi,

As part of the (D)TLS 1.3 profile for IoT [1], Hannes and I would like
to start the deprecation of CCM_8 when used in DTLS.  The reason is its
integrity bounds (i.e., the limit on acceptable forgeries) are abysmally
low (see the full story [2], and  a handy simplification [3]).  This, in
turn, allows a trivial DoS against any DTLS session that uses CCM_8
ciphersuites.  (See also RFC-to-be 9147 [4] for more context.)

Now things get extra interesting for CoRE because
TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 happen to be the only two
mandatory-to-implement ciphersuites in CoAP -- an advice we echoed in
RFC7925 as well.  Hence, we have no stand-by primitive/mode we can fall
back to, which also means we cannot just deprecate, we also need to
promote a new cipher.  Not a great story, but here we are.

It looks like we can no longer postpone an action, but at the same time
we need to understand as much as possible what the real world
implications are before we possibly upend an industry.

To be clear, the gist of our deprecation will look like:

* DTLS SHOULD NOT use CCM_8
* DTLS SHOULD use XYZ instead

And our questions to you CoRE people are:

1. Are you OK with the above?
2. Any preference for XYZ?  Should we recommend CCM, or move to GCM?
   (It looks like the latter would be more inline with stock TLS and
   should therefore improve interoperability.  OTOH, the former would
   be easier to upgrade to in very constrained implementations.)
3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY?
4. Should [1] update Section 9.1 of RFC7252 in the process?

Thanks in advance for your consideration,
Thomas & Hannes

[1] https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/
[2] https://link.springer.com/chapter/10.1007%2F3-540-36492-7_7
[3] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf#page=22
[4] https://www.rfc-editor.org/authors/rfc9147.html#appendix-B.3

---

From: Simon Bernard <[email-masked]>
Date: Mon, 18 Oct 2021 17:29:13 +0200

Hi,

  I guess Hannes better knows that than me, but this will also affects 
LWM2M v1.0 / v1.1 / v1.2 because AFAIK 
TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 is the only one cipher 
recommended and mandatory at client and server side.

> Hannes and I would like
> to start the deprecation of CCM_8 when used in DTLS
Just to be sure, does it concerns only DTLS or TLS too ?

The profile is about (D)TLS 1.3 but I understand this is a "general" 
depreciation, so this affects (D)TLS 1.2 too, or ?

Thx

Simon

Le 18/10/2021 à 15:14, Thomas Fossati a écrit :
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Oct 2021 17:44:09 +0200

I believe we have an ongoing discussion on how bad the situation really is.
What is clear is that CCM_8 is not useful without a regular rekeying regime.
We now have numbers for that; the results hinge on what probability of damage you can accept.
Appendix B.3 of 9147-to-be qualifies itself with "If the goal is to preserve the same margins as other cipher suites,” - well, if you chose CCM_8, clearly that was not the goal.

So I think we need a more detailed discussion of this.
(I do agree with 9147-to-be’s conclusion that "This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable for general use.” — I wouldn’t run my SSH sessions over CCM_8.)

> * DTLS SHOULD use XYZ instead

I think XYZ should be based on Keccak, but of course people will want to make use of their AES hardware…

> GCM

I still don’t believe GCM’s brittleness is appropriate for most IoT applications.

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Mon, 18 Oct 2021 20:55:10 +0200

Hi Thomas,
Hi list

a general recommendation of a cipher suite with stronger MAC for future
deployments may be considered as not too bad. I would appreciate to have
then also rules/best practice advice for using CCM8, for the cases,
where someone has reasons to do so.

The literature seems for to be a mix of a lot of stuff and for me it
raises more questions than it gives answers. E.g. does the findings for
GCM really fit to CCM as well? What are the assumed attacks?
"Brute-force" to bypass the MAC? Or?

In combination with CoAP the answers are more unclear:

- considering IND-CPA: does the usage of varying MIDs and Tokens make
such attacks harder?

- considering INT-CTXT: does parsing the cipher-text as coap-message not
provide additional security and makes brute-force less probable? For me
that leaves mainly "bit-flip" attacks (e.g. flip a CoAP Type bit to 1
results in RST instead of ACK, or a bit in the CoAP Code). But attacking
these bits is also bound to a short time-window (about 4 minutes), which
makes such attacks again less probable (leaving notifications unconsidered).

 > 1. Are you OK with the above?

If the rules for using CCM8 are clear. e.g. append "without reason. If
used, <details on best practice> SHOULD be applied"

 > 2. Any preference for XYZ?

For me CCM is the clear favorite. At least, if it's mainly about the
MAC. That enables the most implementation to follow the mitigation and
not continue to use CCM8 just because alternatives are not that easy to
implement (e.g. hw support).

 > 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY?

Not as mandatory, at least not mandatory for clients.

 > 4. Should [1] update Section 9.1 of RFC7252 in the process?

Depends on the update. Recommend CCM generally instead of CCM8, OK.
FMPOV it would help much more, and will get more acceptance, if the
considerations about CCM8 weakness are clear, and applied to CoAP
specific cases.

(I'm not sure, if switching to CCM is just consider to be less critical,
than try to find out, if CCM8 used with CoAP is really weak. If so, that
should be made clear and leave the usage of CCM8 just as "unknown" and
not as "weak".)

best regards
Achim Kraus

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 19 Oct 2021 08:34:19 +0100

Hi Simon,

> recommended and mandatory at client and server side.

I am not directly involved in LwM2M so I am leaving this to Hannes.

> depreciation, so this affects (D)TLS 1.2 too, or ?

Yes, it'd be version independent: it's the cipher itself that is
problematic, not the way 1.2 or 1.3 use it.

cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 19 Oct 2021 08:35:45 +0100

hi Carsten,

> We now have numbers for that; the results hinge on what probability of

Sure, but what we are ultimately doing is shifting the responsibility of
a hard configuration choice onto the users.  Complex UIs should be
avoided.

> Appendix B.3 of 9147-to-be qualifies itself with "If the goal is to
> preserve the same margins as other cipher suites,” - well, if you
> chose CCM_8, clearly that was not the goal.

You say "if you chose CCM_8", but the thing is that the current MTI
situation doesn't give you a real choice -- the only alternative we
provide is around forward secrecy.  We lack a "general use MTI fallback
and that, I think, hurts us.

> So I think we need a more detailed discussion of this.

yes!

> I think XYZ should be based on Keccak,

I think I see what you are thinking, but I'd wait for NIST's lightweight
crypto outcome before making any concrete recommendation.  It shouldn't
take too long.

> but of course people will want to make use of their AES hardware...

That, but people also want to be able to interop with
${mainstream_tls_stack} without too much hassle.

> I still don’t believe GCM’s brittleness is appropriate for most IoT

I reckon we are past that point.  The deterministic construction in TLS
1.3 makes it very difficult to fall into the "nonce disrespecting" trap
that gave us so many nice CVEs in the past.  Also, similar to
BCP195-bis, we can backport the construction to 1.2 via the IoT profile.

cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 19 Oct 2021 09:39:34 +0100

hi Achim,

> where someone has reasons to do so.

That's actually an interesting point.  I think we need to be mindful
about the risk that saying "SHOULD NOT, however if
${complicated_list_of_conditions} then MAYBE" creates confusion and
ultimately insecurity.
Personally, I'd rather stick to the "simple and nearly-impossible to
misuse UIs" model -- i.e., the good old "boring crypto".

> makes such attacks again less probable (leaving notifications unconsidered).

Yes, the literature is non trivial, especially around the amount of
assumptions one has to make to come out with a number.  And this, to
me, is probably the best counter-argument to having a detailed list of
conditions under which a cipher becomes un/usable, especially for
borderline situations like CCM_8.

> implement (e.g. hw support).

Noted, thanks.

> Not as mandatory, at least not mandatory for clients.

I think if we want to have a stand-by we need to mark it MTI,
otherwise there is no guarantee that in a "main cipher catastrophe" it
can be switched on.

> Depends on the update. Recommend CCM generally instead of CCM8, OK.

Noted.

> considerations about CCM8 weakness are clear, and applied to CoAP

That's super interesting stuff, but it's also a lot of non-trivial work.

> should be made clear and leave the usage of CCM8 just as "unknown" and

cheers, thanks for the input!

-- 
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Oct 2021 11:07:46 +0200

> a hard configuration choice onto the users.  Complex UIs should be

I agree that we need to do something.
I would like to discuss what that something is.

E.g., git uses SHA-1, which has been deprecated about a decade ago.
There is a SHA-256 option now, but adoption is slow (and probably will be until someone does serious mischief with SHA-1, which is not too easy).
I’d avoid stopping to use git until everybody has switched to SHA—256.

> and that, I think, hurts us.

As Achim said, CCM (without _8) is the obvious fallback (fall-forward, if you prefer), and we should have a consensus document that points that out.

>>> * DTLS SHOULD NOT use CCM_8

… except if [___]  (fill the blank here)

> crypto outcome before making any concrete recommendation.  It shouldn't

Exactly, and that really should be the next major step before everybody loses interest, with CCM as the stopgap.

> ${mainstream_tls_stack} without too much hassle.

But you always could choose a mainstream cipher suite, if that was important.

> BCP195-bis, we can backport the construction to 1.2 via the IoT profile.

OK, but I’d like to see the numbers (how do you do a 64-bit authentication tag, if that’s all you need and you do need the compactness?).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Oct 2021 07:18:04 -0400

> What is clear is that CCM_8 is not useful without a regular rekeying

Understood, but are there actually algorithms where that isn't true?
Even AES128-CBC runs out.

    > (I do agree with 9147-to-be’s conclusion that "This analysis supports
    > the view that TLS_AES_128_CCM_8_SHA256 is not suitable for general
    > use.” — I wouldn’t run my SSH sessions over CCM_8.)

This statement surprises me actually.
a) SSH sessions do have a regular rekeying regime!
b) many SSH sessions are relatively short, often minutes to hours.  Yes,
   sometimes weeks to months.
c) Yes, some SSH sessions move multiple dozen gigabytes of data (backup sessions).
   But they can rekey, and the sessions usually start/end every day.

This is not to say you should use CCM_8 with your SSH-based backups, but I
don't see this as a particularly downside.

    > to make use of their AES hardware…

CCM_8 has been a thorn in the side of IoT to cloud in my experience.
I'm all for an XYZ that is strong enough to be part of the standard web set.
I have no opinion about Keccak.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Achim Kraus <[email-masked]>
Date: Wed, 20 Oct 2021 07:30:07 +0200

Hi Micheal,

 > CCM_8 has been a thorn in the side of IoT to cloud in my experience.

in my experience, TCP, RSA and X509 are much more holding up (small,
embedded) devices to connect to the cloud. OK, though I'm one of the
committer of Eclipse/Calfornium, my personal preference is obvious.
(Some shameless advertisement: The upcoming release 3.0 of that open
source project with the "DTLS Connection ID build in load balancer
support", together with a general improved cloud UDP support (k8s),
makes it much easier (and cheaper), to connect devices scalable and
reliable to the cloud.)

 > I'm all for an XYZ that is strong enough to be part of the standard
web set.

5 years ago, I recognized, that have a mandatory small set of cipher
suites makes it much easier to use it. Your point, that the big cloud
provider doesn't care about that, is in my opinion also the result of
much less request from iot, as forecasted.

I still think, to distinguish from DTLS "standalone" and "coap" usage,
makes sense. In my opinion for "standalone", it's OK to change the
recommendation. For CoAP I tried to point, that "unknown (weak)" is not
"(proven) weak". My current ideas on that are:

- check for each deployment, if the 8 bytes saving is relevant. For
normal IP(v4) traffic we have 20 bytes IP, 8 bytes UDP, 13 bytes DTLS
1.2 record, 8 bytes nonce, and 8 or 16 bytes MAC. That's in sum 57 vs.
65 (or about 12%). Adding a CoAP message with 32 byte, the relative
saving is less. In some cases it's more the MTU, which makes the 8 bytes
saving relevant in order not to use 2 low-layer-messages.

@Carsten: maybe you can add the numbers for more critical transport layers.

- test each deployments with both, CCM and CCM8. That should provide the
experience to chose a good match.

- a client, which chose CCM_8, SHOULD also offer CCM in the ClientHello.
That enables the operators of deployments to switch to CCM in the
future, if the "CCM_8/CoAP" turns out to be too weak.

Best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Wed, 20 Oct 2021 07:41:28 +0200

Hi Thomas,

> That's super interesting stuff, but it's also a lot of non-trivial work.

Unfortunately. Let me even add one more CoAP question:

- is using a 4 bytes ACK (2 bytes fixed, 2 bytes variable, relevant
lifetime up to 120s) for encrypted messages creating an attack surface?
Otherwise, fixing CCM8 may be in vain, if the 4 bytes stuff is the
larger hole.

I guess, that coap specific questions will unfortunately not be answered
in the next time.

best regards
Achim

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 09:38:34 +0100

hey Achim!

> Otherwise, fixing CCM8 may be in vain, if the 4 bytes stuff is the

I don't think so, it's the size of the key (and of the integrity tag)
that is relevant.

cheers,
-- 
Thomas

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 09:46:21 +0100

hi Michael,

> I'm all for an XYZ that is strong enough to be part of the standard web set.

If that is the case, then maybe full-tag CCM (which has the otherwise
excellent property of being easy to upgrade to) may not be the best
choice:

$ openssl version
OpenSSL 1.1.1l  24 Aug 2021
both
$ openssl ciphers -s -tls1_2 | sed -e 's/:/\n/g' | grep CCM
$ openssl ciphers -s -tls1_3 | sed -e 's/:/\n/g' | grep CCM
return the empty set :-(

GCM would seem like a better choice under that requirement.

cheers, t

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Oct 2021 10:55:03 +0200

> excellent property of being easy to upgrade to) may not be the best

So you now switched to solving a different problem:
Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, and is supported in the default list of openssl ciphers (where that can change any moment).

That is an interesting problem, but maybe not the one we are solving here.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Oct 2021 10:58:35 +0200

> Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, and is supported in the default list of openssl ciphers (where that can change any moment).

And the bonus of course is having an 8-byte version that as well (that is supported by default by openssl, to ensure that this is entirely impossible to achieve).

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Wed, 20 Oct 2021 11:05:35 +0200

Hi Thomas,

 > $ openssl ciphers -s -tls1_3 | sed -e 's/:/\n/g' | grep CCM

but the CCM stuff could be enabled, even CCM8.

In my opinion, for the cloud-connectivity, it's more interesting, what
the big-scaler offers, and not so, what openssl does on default.

best regards
Achim

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 10:16:14 +0100

> Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, and is supported in the default list of openssl ciphers (where that can change any moment).

I was providing one (to me surprising) datapoint which seemed relevant
to Michael's comment.
(The comment being "I'm all for an XYZ that is strong enough to be
part of the **standard web set.**")

-- 
Thomas

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 10:42:39 +0100

hi Achim,

> but the CCM stuff could be enabled, even CCM8.

Sure, but sometimes this is a configuration choice that others make
for you and that you can't control.
What I'm saying is -- WRT Michael's desideratum -- GCM may be a better fit.

> the big-scaler offers, and not so, what openssl does on default.

Good point.  A quick googling returns these results:

Amazon IoT, no CCM:
https://docs.aws.amazon.com/iot/latest/developerguide/transport-security.html

Azure IoT, no CCM:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support

Google IoT, no CCM:
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

cheers, thanks

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 10:44:50 +0100

> And the bonus of course is having an 8-byte version that as well (that is supported by default by openssl, to ensure that this is entirely impossible to achieve).

Not sure I understand this comment: irrespective of what openssl does,
what other chiphersuite provides 8-byte auth tags?  If the requirement
is an 8-byte auth tag version you are left with no other choice than
CCM.  Is this your requirement?

-- 
Thomas

---

From: Achim Kraus <[email-masked]>
Date: Wed, 20 Oct 2021 13:12:36 +0200

Hi Thomas,

great!

Even though, I would still prefer CCM (maybe additional), because the
migration costs for the CCM_8 deployments/implementations will be low.

That may be important for the acceptance in relation with CoAP,
especially, if the CoAP related analysis will not be done.

best regards
Achim

---

From: Achim Kraus <[email-masked]>
Date: Wed, 20 Oct 2021 13:25:09 +0200

Hi Thomas,

> I don't think so, it's the size of the key (and of the integrity tag) > that is relevant.
I'm not that sure about this.
(I already wrote, that the amount of papers to read is mixing up.)

In "Limits on Authenticated Encryption Use in TLS", 2017,
"3 Computing the Bounds" the input length is considered!

And again, if 2 bytes are fix, that may be also an issue.

best regards
Achim

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Oct 2021 13:33:20 +0200

> CCM.  Is this your requirement?

If we want to replace CCM_8, it would be natural to choose something that has similar performance characteristics.
I can imagine openssl doesn’t have a 64-bit authenticator option; maybe we need to cough up one.
(Or we could leave CCM_8 in place, i.e., deprecate it slightly less.)

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 13:06:15 +0100

hi Achim!

On Wed, Oct 20, 2021 at 12:25 PM Achim Kraus <[email-masked]> wrote:
> > I don't think so, it's the size of the key (and of the integrity tag) that is relevant.

Correct, but in both (1) and (5) (integrity and confidentiality,
respectively), \sigma and \ell are in the numerator, so the smaller
the better.

> And again, if 2 bytes are fix, that may be also an issue.

That shouldn't be an issue since all modern ciphers are (supposed to
be) KPA-resistant.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 13:08:45 +0100

> migration costs for the CCM_8 deployments/implementations will be low.

The smoothness of the upgrade path here is unquestionable :-)

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 20 Oct 2021 15:35:49 +0100

> If we want to replace CCM_8, it would be natural to choose something that has similar performance characteristics.

By performance characteristic I assume you refer to the wire image
size, correct?  If so, that's exactly the problem: the small tag size
(which is the major factor in the size reduction) is what makes CCM_8
a bad choice unless
${insert_long_and_complicated_list_of_considerations}.  However, I
strongly suspect we'd end up in a similar situation with regards to
the integrity bounds if we hypothetically came up with a ciphersuite
based on a different primitive and/or mode but sporting similarly
sized auth tags. So ... (continues below)

> I can imagine openssl doesn’t have a 64-bit authenticator option; maybe we need to cough up one.

(I guess s/openssl/TLS/ ?)

... if you mean defining a new XYZ_8 ciphersuite I'd rather stay with
CCM_8 since the analysis is already done and implementations exist.

> (Or we could leave CCM_8 in place, i.e., deprecate it slightly less.)

By "deprecating slightly less" what do you mean exactly?  Is it:
* MAY CCM_8 if ...
instead of
* SHOULD NOT CCM_8 unless ...
and
* MUST/SHOULD XYZ
?

-- 
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Oct 2021 16:46:30 +0200

> sized auth tags. So ... (continues below)

The NIST document that was earlier referenced in this thread does deprecated 32-bit tags (no wonder), but does leave room for 64-bit tags.
So I was assuming they are still in the realm of consideration.

> CCM_8 since the analysis is already done and implementations exist.

Which works for me :-)
I’d like to have John’s numbers written up somewhere so we can point to the usage limitations.

> * SHOULD NOT CCM_8 unless ...

I used wishy-washy words because I’m not sure of the language either.
Instead of carefully selecting a word of deprecation, I think we should be explicit about the remaining area of application.  We can then put in a strong word for applications outside that boundary.

* MUST NOT be used with manually keyed environments
* SHOULD only be used where the performance difference between 8-byte and 16-byte tags is a deciding factor in the viability of the application, and where the somewhat increased risk (see table 1) is acceptable.
* MUST be used with a mechanism that keeps visibility over whether the usage limits are being reached.

(Well, 1 follows from 3, but better be explicit.)
Insert your requirements (and table 1) here...

Grüße, Carsten