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

From: Thomas Fossati <[email-masked]>
Date: Mon, 21 Mar 2022 20:50:56 +0000

Hi all,

Coming back to this thread to give you an update on the current (draft) proposal:

https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-04.html#section-18

Please have a look and let us know what you think.

Thanks!

From: core <[email-masked]> on behalf of Carsten Bormann <[email-masked]>
Date: Wednesday, 20 October 2021 at 15:47
To: Thomas Fossati <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] time to start the deprecation of CCM_8?
On 2021-10-20, at 16:35, Thomas Fossati <[email-masked]> wrote:
>
> On Wed, Oct 20, 2021 at 1:41 PM Carsten Bormann <[email-masked]> wrote:
>> On 20. Oct 2021, at 11:44, Thomas Fossati <[email-masked]> wrote:
>>>
>>> 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?
>>
>> 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)

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.

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

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

>> (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

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

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Mar 2022 23:31:57 +0200

> Please have a look and let us know what you think.

I have not been able to parse that CFRG draft properly to really
understand what their limits mean.

I.e. the assumptions there seem to be for normal internet traffic, but
if we assume IoT use case, for example IEEE 802.15.4, and use say
maximum packet size of 127 bytes (normal packet size is most likely
something like 80-100 bytes), maximum data rate of 250 kBit/s, i.e.
about 300-400 packets / second, how long would one of those forgery
attempts take in seconds?

I would assume that on environments which are not that constrained
(i.e., has packet sizes over 0.5 kB, or speed over 1MBit/s) do not
need to save bytes and use CCM_8. Those environments can (and should)
use normal CCM, so only the very constrained devices shuld be of
interest when talking about CCM_8.
-- 
[email-masked]

---

From: Achim Kraus <[email-masked]>
Date: Tue, 22 Mar 2022 10:17:59 +0100

Hi Tero,

as I wrote last year in
https://mailarchive.ietf.org/arch/msg/core/qFNAXTWVWr8X0ROLPlbvSy965nk/

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

The saving isn't that large, at least, if there is no mistake in that
calculation. For cases with "header compression", someone, who is more
common to that, may provide an additional calculation.

For me the question is:
- is it easier (less effort) to go with the TLS mainstream and
"deprecate CCM8".
- or to dig into the "57 bit assumption", which causes the pain for the
"64 bit MAC".

For the second, we can try to get some help from one of the crypto
experts, to get more background for the 57 bit. But I would appreciate,
if that is not only my question and more of that group raise their interest.
For the most of my usage, CCM will do it, so personally I tend to go for
the first, just use ccm without dig into the 57bit.

best regards
Achim

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 23 Mar 2022 15:25:01 +0000

Hi Tero,

Thanks very much for you comments.

> Tero Kivinen <[email-masked]> wrote:
> Thomas Fossati writes:

We are trying to avoid writing this stuff down because it tends to
depend on a lot of variables and the tradeoff is not always clear.
Marco and Rikard are trying to provide that kind of guidance in [1] for
OSCORE, and while I find their effort extremely laudable (kudos!), I
also reckon that that kind of approach would not necessarily make the
life easier to operators and developers alike.

> interest when talking about CCM_8.

Yep, that's the gist of the recommendation in [2], which basically
amount to providing an interoperable and (as much as possible) risk-free
fallback for CoAP, and more generally IoT deployments.

cheers, t

[1] https://www.ietf.org/archive/id/draft-ietf-core-oscore-key-update-01.html#appendix-A
[2] https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-04.html#section-18